Never Ending Security

It starts all here

Category Archives: Encryption

650.445: PRACTICAL CRYPTOGRAPHIC SYSTEMS



READINGS & SUGGESTED PRESENTATION TOPICS


Protocols

  1. Crosby, Goldberg, Johnson, Song, Wagner: Cryptanalyzing HDCP (2001)

  2. Wagner, Schneier: Analysis of the SSL 3.0 Protocol

  3. Lucks, Schuler, Tews, Weinmann, Wenzel: Security of DECT

  4. Kohno: Analysis of WinZip Encryption

  5. Stubblefield, Ioannidis, Rubin: Breaking WEP

  6. Bellare, Kohno, Namprempre: Breaking and Repairing SSH

  7. Burrows, Abadi and Needham: A Logic of Authentication

  8. DTLA: DTCP Additional Localization Protocol

Side Channel Attacks

  1. Bar-el: Introduction to Side Channel Attacks (white paper)

  2. Kocher: Timing attack on RSA & DL systems

  3. Brumley, Boneh: Remote Timing Attacks are Practical

  4. Bernstein: Cache Timing Attack on AES.  Osvik, Shamir, Tromer: Attacks and Countermeasures

  5. Eisenbarth, Kasper, Moradi, Paar, Salmasizadeh, Shalmani: Attacking KeeLoq (SpringerLink)

  6. Shamir, Tromer: Acoustic Cryptanalysis

  7. Pellegrini, Bertacco, Austin: Fault-Based Attack of RSA Authentication

  8. Aciicmez, Koc, Seifert: Branch Prediction Analysis (very advanced)

Dictionary Attacks: Optimization & Mitigation

  1. Alexander: Password Protection for Modern OSes

  2. RSA Laboratories: PKCS #5 2.0: Password-Based Cryptography Standard

  3. Provos and Mazières: “Future-adaptable” password schemes

  4. Stamp: Once Upon a Time Space Tradeoff

  5. Oeschslin: Rainbow Tables (includes papers & demo)

  6. Canetti, Halevi, Steiner: Mitigating (offline) Dictionary Attacks with Reverse-Turing Tests

    Securing Internet Infrastructure

  7. Jackson, Barth, Bortz, Shao, Boneh: Protecting Browsers from DNS Rebinding Attacks

  8. Kaminsky: It’s the End of the (DNS) Cache As We Know It (Black Hat 2008 – 101MB)

  9. DNSSEC.net: DNS Security Extensions (standards & resources)

  10. Ptacek: A case against DNSSEC

  11. Kent, Lynn and Seo: Secure BGP

  12. BBN.com: Secure BGP resources

Digital Rights Management & Conditional Access

  1. Lawson: Designing and Attacking DRM (presentation)

  2. Edwards: A technical description of the Content Scrambling System (CSS)

  3. Henry, Sui, Zhong: Overview of AACS — and full AACS Specification

  4. ISE: A Comparison of SPDC (technology behind BD+) and AACS (2005)

  5. Craver, Wu, Liu, Stubblefield, Swartzlander, Wallach, Dean, Felten: Watermarking & SDMI

  6. Kuhn: Analysis of the Nagravision Video Scrambling Method (analog scrambling)

  7. Naor, Naor and Lotspiech: Revocation and Tracing Schemes for Stateless Receivers

Software, Physical Security, Backdoors

  1. Halderman et al.: Cold Boot Attacks on Encryption Keys & RSA Key Reconstruction

  2. Young, Yung: Cryptovirology: extortion-based security threats and countermeasures (IEEE)

  3. Dowd: Application-Specific Attacks: Leveraging the ActionScript Virtual Machine

  4. Steil: 17 Mistakes Microsoft Made in the XBox Security (2005)

  5. Bartolozzo et al.: Attacking and Fixing PKCS#11 Security Tokens

  6. Bardou et al.: Efficient Padding Oracle Attacks on Cryptographic Hardware

Privacy and Anonymity

  1. Dingledine, Mathewson, Syverson: Tor: The Second Generation Onion Router

  2. McCoy, Bauer, Grunwald, Kohno, Sicker: Analyzing Tor Usage

  3. Murdoch, Danezis: Low-cost Traffic Analysis of Tor

  4. Murdoch: Hot Or Not: Using clock skew to locate hidden services

  5. Wang, Chen, Jajodia: Tracking Anonymized VoIP Calls

Hash Functions and Random Oracles

  1. Coron, Dodis, Malinaud, Puniya: Merkle-Damgård Revisited

  2. Wang, Yu: How to break MD5 and other hash functions

  3. Stevens, Lenstra, de Weger: Target collisions for MD5

  4. Kaminsky: MD5 To Be Considered Harmful Someday

  5. Sotirov et al.: MD5 considered harmful today (building a rogue CA cert)

  6. Wang, Yin, Yu: SHA1 broken (at least, on its way…)

  7. NIST: “SHA3” competition: list of first round candidates (December 2008)

  8. Canetti, Goldreich, Halevi: Random oracles revisited, and…

  9. Bellare, Boldyreva, Palacio: A more natural uninstantiable Random-Oracle-Model scheme

  10. Coron, Patarin, Seurin: The random oracle model and the ideal cipher model are equivalent

  11. Bellare, Canetti, Krawczyk: HMAC

Symmetric Crypto

  1. Bellare, Namprempre: Authenticated encryption, generic composition

  2. Ferguson: Authentication weaknesses in GCM.  McGrew, Viega: Response & Update.

Public Key Crypto

Bleichenbacher: CCA Attacks against Protocols (SSL) based on PKCS #1

Bellare, Rogaway: Optimal Asymmetric Encryption Padding (OAEP)

Manger: CCA Attacks against Implementations of OAEP

Bernstein: An Introduction to Post-Quantum Cryptography

Random Number Generation

  1. Dorrendorf, Gutterman, Pinkas: RNG Weaknesses in Windows 2000

  2. Gutterman, Pinkas: Flaws in the Linux RNG

  3. Barker, Kelsey: NIST Special Pub. 800-90: Recommendations for PRNGs

  4. Kelsey, Schneier, Wagner, Hall: Cryptanalytic attacks on PRNGs

  5. Schoenmakers, Sidorenko: Dual EC not kosher

  6. Shumow, Ferguson: There May Be a Backdoor in Dual EC.

  7. Keller: ANSI X9.31 (Block cipher-based PRNG). Various artists: FIPS 186-2 (see Appendix 3)

Implementation Issues

  1. Gutmann: Lessons Learned in Implementing and Deploying Crypto Software

  2. Berson: Security Evaluation of Skype (2005, conducted at Skype’s request)

  3. Biondi, Desclaux: Silver Needle in the Skype (2006, REing of Skype binary)

Financial Services

  1. Berkman, Ostrovsky: The Unbearable Lightness of PIN cracking

  2. Bond, Zieliński: Decimalisation table attacks for PIN cracking

  3. Murdoch, Drimer, Anderson, Bond: Chip and PIN is Broken

RFID and Wireless

  1. Nohl, Evans, Starbug, Plötz: Reverse-Engineering a Cryptographic RFID Tag

  2. Bono, Green, Stubblefield, Juels, Rubin, Szydlo: Security Analysis of TI DST Tags

Misc.

  1. Halperin et al.: Pacemakers and ICDs (no crypto)

  2. Ellis: Non-secret Encryption (historically very interesting)

  3. TheGrugq: Opsec for Freedom Fighters

Advertisements

How Do We Build Encryption Backdoors?


They say that history repeats itself, first as tragedy, then as farce. Never has this principle been more apparent than in this new piece by Washington Post reporters Ellen Nakashima and Barton Gellman: ‘As encryption spreads, U.S. grapples with clash between privacy, security‘.

The subject of the piece is a renewed effort by U.S. intelligence and law enforcement agencies to mandate ‘backdoors’ in modern encryption systems. This is ostensibly a reaction to the mass adoption of strong encryption in smartphones, and a general fear that police are about to lose wiretapping capability they’ve come to depend on.

This is not the first time we’ve been here. Back in the 1990s the Federal government went as far as to propose a national standard for ‘escrowed’ telephone encryption called the ‘Clipper’ chip. That effort failed in large part because the technology was terrible, but also because — at least at the time — the idea of ordinary citizens adopting end-to-end encryption was basically science fiction.

Thanks to the advent of smartphones and ‘on-by-default’ encryption in popular systems like Apple’s iMessage, and WhatsApp, Americans are finally using end-to-end encryption at large scale and seem to like it. This is scaring the bejesus out of the powers that be.

Hence crypto backdoors.

As you might guess, I have serious philosophical objections to the idea of adding backdoors to any encryption system — for excellent reasons I could spend thousands of words on. But I’m not going to do that. What I’d like to do in this post is put aside my own value judgements and try to take these government proposals at face value.

Thus the question I’m going to consider in this post:

Let’s pretend that encryption backdoors are a great idea. From a purely technical point of view, what do we need to do to implement them, and how achievable is it?

First some background.

End-to-end encryption 101

Modern encryption schemes break down into several categories. For the purposes of this discussion we’ll consider two: those systems for which the provider holds the key, and the set of systems where the provider doesn’t.

We’re not terribly interested in the first type of encryption, which includes protocols like SSL/TLS and Google Hangouts, since those only protect data at the the link layer, i.e.,until it reaches your provider’s servers. I think it’s fairly well established that if Facebook, Apple, Google or Yahoo can access your data, then the government can access it as well — simply by subpoenaing or compelling those companies. We’ve even seen how this can work.

The encryption systems we’re interested all belong to the second class — protocols where even the provider can’t decrypt your information. This includes:

This seems like a relatively short list, but in practice w’re talking about an awful lot of data. The iMessage and WhatsApp systems alone process billions of instant messages every day, and Apple’s device encryption is on by default for everyone with a recent(ly updated) iPhone.

How to defeat end-to-end encryption

If you’ve decided to go after end-to-end encryption through legal means, there are a relatively small number of ways to proceed.

By far the simplest is to simply ban end-to-end crypto altogether, or to mandate weak encryption. There’s some precedent for this: throughout the 1990s, the NSA forced U.S. companies to ship ‘export‘ grade encryption that was billed as being good enough for commercial use, but weak enough for governments to attack. The problem with this strategy is that attacks only get better — but legacy crypto never dies.

Fortunately for this discussion, we have some parameters to work with. One of these is that Washington seems to genuinely want to avoid dictating technological designs to Silicon Valley. More importantly, President Obama himself has stated that “there’s no scenario in which we don’t want really strong encryption“. Taking these statements at face value should mean that we can exclude outright crypto bans, mandated designs, and any modification has the effect of fundamentally weakening encryption against outside attackers.

If we mix this all together, we’re left with only two real options:

  1. Attacks on key distribution. In systems that depend on centralized, provider-operated key servers, such as WhatsApp, Facetime, Signal and iMessage,** governments can force providers to distribute illegitimate public keys, or register shadow devices to a user’s account. This is essentially a man-in-the-middle attack on encrypted communication systems.
  2. Key escrow. Just about any encryption scheme can be modified to encrypt a copy of a decryption (or session) key such that a ‘master keyholder’ (e.g., Apple, or the U.S. government) can still decrypt. A major advantage is that this works even for device encryption systems, which have no key servers to suborn.

Each approach requires some modifications to clients, servers or other components of the system.

Attacking key distribution

Key lookup request for Apple iMessage. The phone
number is shown at top right, and the response at bottom left.

Many end-to-end encrypted messaging systems, including WhatsApp and iMessage, generate a long-term public and secret keypair for every device you own. The public portion of this keypair is distributed to anyone who might want to send you messages. The secret key never leaves the device.

Before you can initiate a connection with your intended recipient, you first have to obtain a copy of the recipient’s public key. This is commonly handled using a key server that’s operated by the provider. The key server may hand back one, or multiple public keys (depending on how many devices you’ve registered). As long as those keys all legitimately belong to your intended recipient, everything works fine.

Intercepting messages is possible, however, if the provider is willing to substitute its own public keys — keys for which it (or the government) actually knows the secret half. In theory this is relatively simple — in practice it can be something of a bear, due to the high complexity of protocols such as iMessage.

Key fingerprints.

The main problem with key distribution attacks is — unlike a traditional wiretap — substitute keys are at least in theory detectable by the target. Some communication systems, like Signal, allow users to compare key fingerprints in order to verify that each received the right public key. Others, like iMessage and WhatsApp, don’t offer this technology — but could easily be modified to do so (even using third party clients). Systems like CONIKS may even automate this process in the future — allowing applications to monitor changes to their own keys in real time as they’re distributed by a server.

A final, and salient feature on the key distribution approach is that it allows only prospective eavesdropping — that is, law enforcement must first target a particular user, and only then can they eavesdrop on her connections. There’s no way to look backwards in time. I see this is a generally good thing. Others may disagree.

Key Escrow 

Structure of the Clipper ‘LEAF’.

The techniques above don’t help much for systems without public key servers, Moreover, they do nothing for systems that don’t use public keys at all, the prime example being device encryptionIn this case, the only real alternative is to mandate some sort of key escrow.

Abstractly, the purpose of an escrow system is to place decryption keys on file (‘escrow’ them) with some trusted authority, who can break them out when the need arises. In practice it’s usually a bit more complex.

The first wrinkle is that modern encryption systems often feature many decryption keys, some of which can be derived on-the-fly while the system operates. (Systems such as TextSecure/WhatsApp actually derive new encryption keys for virtually every message you send.) Users with encrypted devices may change their password from time to time.

To deal with this issue, a preferred approach is to wrap these session keys up (encrypt them) under some master public key generated by the escrow authority — and to store/send the resulting ciphertexts along with the rest of the encrypted data. In the 1990s Clipperspecification these ciphertexts were referred to as Law Enforcement Access Fields, or LEAFs.***

With added LEAFs in your protocol, wiretapping becomes relatively straightforward. Law enforcement simply intercepts the encrypted data — or obtains it from your confiscated device — extract the LEAFs, and request that the escrow authority decrypt them. You can find variants of this design dating back to the PGP era. In fact, the whole concept is deceptively simple — provided you don’t go farther than the whiteboard. 

Conceptual view of some encrypted data (left) and a LEAF (right).

It’s only when you get into the details of actually implementing key escrow that things get hairy. These schemes require you to alter every protocol in your encryption system, at a pretty fundamental level — in the process creating the mother of all security vulnerabilities — but, more significantly, they force you to think very seriously about who you trust to hold those escrow keys.

Who does hold the keys?

This is the million dollar question for any escrow platform. The Post story devotes much energy to exploring various proposals for doing this.

Escrow key management is make-or-break, since the key server represents a universal vulnerability in any escrowed communication system. In the present debate there appear to be two solutions on the table. The first is to simply dump the problem onto individual providers, who will be responsible for managing their escrow keys — using whatever technological means they deem appropriate. A few companies may get this right. Unfortunately, most companies suck at cryptography, so it seems reasonable to believe that the resulting systems will be quite fragile.

The second approach is for the government to hold the keys themselves. Since the escrow key is too valuable to entrust to one organization, one or more trustworthy U.S. departments would hold ‘shares‘ of the master key, and would cooperate to provide decryption on a case-by-case basis. This was, in fact, the approach proposed for the Clipper chip.

The main problem with this proposal is that it’s non-trivial to implement. If you’re going to split keys across multiple agencies, you have to consider how you’re going to store those keys, and how you’re going to recover them when you need to access someone’s data. The obvious approach — bring the key shares back together at some centralized location — seems quite risky, since the combined master key would be vulnerable in that moment.

A second approach is to use a threshold cryptosystem. Threshold crypto refers to a set of techniques for storing secret keys across multiple locations so that decryption can be done in place without recombining the key shares. This seems like an ideal solution, with only one problem: nobody has deployed threshold cryptosystems at this kind of scale before. In fact, many of the protocols we know of in this area have never even been implemented outside of the research literature. Moreover, it will require governments to precisely specify a set of protocols for tech companies to implement — this seems incompatible with the original goal of letting technologists design their own systems.

Software implementations

A final issue to keep in mind is the complexity of the software we’ll need to make all of this happen. Our encryption software is already so complex that it’s literally at the breaking point. (If you don’t believe me, take a look at OpenSSL’s security advisories for the last year) While adding escrow mechanisms seems relatively straightforward, it will actually require quite a bit of careful coding, something we’re just not good at.

Even if we do go forward with this plan, there are many unanswered questions. How widely can these software implementations be deployed? Will every application maker be forced to use escrow? Will we be required to offer a new set of system APIs in iOS, Windows and Android that we can use to get this right? Answering each of these questions will result in dramatic changes throughout the OS software stack. I don’t envy the poor developers who will have to answer them.

How do we force people to use key escrow?

Leaving aside the technical questions, the real question is: how do you force anyone to do this stuff? Escrow requires breaking changes to most encryption protocols; it’s costly as hell; and it introduces many new security concerns. Moreover, laws outlawing end-to-end encryption software seem destined to run afoul of the First Amendment.

I’m not a lawyer, so don’t take my speculation too seriously — but it seems intuitive to me that any potential legislation will be targeted at service providers, not software vendors or OSS developers. Thus the real leverage for mandating key escrow will apply to the Facebooks and Apples of the world. Your third-party PGP and OTR clients would be left alone, for the tiny percentage of the population who uses these tools.

Unfortunately, even small app developers are increasingly running their own back-end servers these days (e.g., Whisper Systems and Silent Circle) so this is less reassuring than it sounds. Probably the big takeaway for encryption app developers is that it might be good to think about how you’ll function in a world where it’s no longer possible to run your own back-end data transport service — and where other commercial services may not be too friendly to moving your data for you.

In conclusion

If this post has been more questions than answers, that’s because there really are no answers right now. A serious debate is happening in an environment that’s almost devoid of technical input, at least from technical people who aren’t part of the intelligence establishment.

And maybe that by itself is reason enough to be skeptical.

Notes:

  • Not an endorsement. I have many thoughts on Telegram’s encryption protocols, but they’re beyond the scope of this post.

** Telegram is missing from this list because their protocol doesn’t handle long term keys at all. Every single connection must be validated in person using a graphical key fingerprint, which is, quite frankly, terrible.

*** The Clipper chip used a symmetric encryption algorithm to encrypt the LEAF, which meant that the LEAF decryption key had to be present inside of every consumer device. This was completely nuts, and definitely a bullet dodged. It also meant that every single Clipper had to be implemented in hardware using tamper resistant chip manufacturing technology. It was a truly awful design.

Linux Gentoo full disk encryption (FDE) with LUKS and LVM2


Creating your encrypted partition

As before using fdisk (or whatever partition tool you prefer) create to partitions.

/dev/sda1

/dev/sda2

sda1 above is set to bootable and is of filesystem type 83 (linux). sda2 is of the same filesystem type.

I normally use ext2 for my boot partition but you can use whatever you like.

mkfs.ext2 /dev/sda1

Now we will prepare our encrypted partition. Load the following modules if they aren’t already available.

modprobe dm-crypt
modprobe aes
modprobe sha256

Now format the partition with cryptsetup.

cryptsetup luksFormat /dev/sda2

Create your password and be sure to memorize it.

Now open the encrypted partition.

cryptsetup luksOpen /dev/sda2 main

Enter your password.

You will now have access to your partition in /dev/mapper/main. Keep in mind the name “main” was chosen randomly and is just the name of the file that will represent the unlocked partition. You can change it every time you unlock it if you want.

Now create the physical volume and volume group.

pvcreate /dev/mapper/main
vgcreate [vgname] /dev/mapper/main

Now we create two logical volumes in our new volume group [vgname].

lvcreate -L 1G -n swap [vgname]
lvcreate -L XG -n root [vgname]

Here I chose 1G for the swap partition size. X is just the size of the remaining space available to be for the root partition. You can find the remaining space available with the following command.

vgdisplay

If you look at the value for the field “PE Total” you will see how much space is available for allocation. Other fields can also be helpful to such as “allocated” and “free”.

At this point you now have two logical volumes for swap and root respectively. You can now format them as you normally would.

mkswap /dev/vg/vg-swap
mkfs.ext4 /dev/vg/vg-root

At this point the rest of the gentoo handbook applies as normal. The exception is that you will need an initramfs to perform the unlocking of your encrypted partition. After you create your initramfs you will need to make sure to reference it in your grub config or whatever you use to bootstrap your OS installation.

Creating the initramfs

Now onto creating the minifilesystem loaded by the kernel first. This is necessary to decrypt your encrypted partition to allow the boot process to continue.

Create a directory to work under, as we’ll be creating a filesystem.

mkdir initramfs
cd initramfs

Now create the directories with the following.

mkdir -p bin lib dev etc mnt/root proc root sbin sys

Now copy of the usual device nodes from your existing filesystem into your initramfs.

cp -a /dev/{null,console,tty,sda1,sda2} .

Feel free to copy other devices as needed. Also if your drive is not sdaX change it accordingly.

You will want to copy over various utilities that you might want to use as well. Just be sure they are compiled with the “static” use flag as any dependencies binaries have will also need to be copied. To avoid copying over huge chains of dependencies just compile the files you want statically so you won’t have to worry about this.

Since we are using cryptsetup and lvm we will need to copy our cryptsetup and lvm binaries (built statically)  onto the filesystem.

Once you build them statically just copy them into the ./sbin directory.

Its also typical to build busybox and add it to ./bin so feel free to customize.

The main part of the initramfs is the init script in the root of the initramfs. It is what gets executed immediately after the kernel boots and then it, once the real root partition is decrypted, calls the main init script.

Below is part of my initramfs init script. This is the minimum requirement to accomplish the decryption and booting we need.

#mount proc and sys filesystems

mount  -t proc none /proc

mount -t sysfs none /sys

echo 0 > /proc/sys/kernel/printk

# decrypt

/sbin/cryptsetup luksOpen /dev/sda2 main

/sbin/lvm vgscan –mknodes

/sbin/lvm lvchange -aly vg/swap

/sbin/lvm lvchange -aly vg/root

#mount

mount /dev/mapper/vg-root /mnt/root

#cleanup

umount /proc

umount /sys

# and we continue

exec switch_root /mnt/root /sbin/init

Save this into your init script.

chmod u+x init

Some of the things I put in here could use a bit of explanation.

The echo 0 disables kernel printk debug messages. I did this because these kernel messages come up a lot, even during typing of my password. I found it irritating so I disabled it during the initramfs process.

The cryptsetup line is pretty straightforward as it lets us unlock our encrypted partition. The following lvm lines are to enable our logical volumes and make the representative device nodes in /dev/mapper.

The final part is where the script hands off control to the decrypted init script on the root partition. Keep in mind that there is a space between the /mnt/root and /sbin/init.

Once you’ve created the filesystem to your needs you must build this mini filesystem into an initrd gzipped cpio type file to be included along with your kernel. To build the initramfs file you can issue the following command.

find . -print0 | cpio --null -ov --format=newc | gzip -9 > /boot/my-initramfs.cpio.gz

Name your initramfs.cpio.gz file however you like and make sure to include it in your bootloader. For grub it would look something like the following.

title=My Linux

root (hd0,0)

kernel /boot/my-kernel

initrd /boot/my-initramfs.cpio.gz

At this point you can reboot your system and test your setup. Your initramfs should load and allow you to enter your encrypted partition password. After that bootup should continue as usual. You can of course make your init script smarter by checking for a correct login or spawning a busybox shell if you need to. These options are left to you.

LVM device nodes

Another thing you might want to do is add a startup script to be executed by your system during boot that will re-create the lvm device nodes as they will no longer exist when the initramfs is removed from memory after it is done. If you use swap your system won’t be able to find /dev/vg/swap since the node for it wouldn’t have been created. I’m not sure why lvm doesn’t automatically see this but I added a simple script to my /etc/local.d/ called 40_fixlvmnodes.start that has the following contents.

#!/bin/bash

echo “creating lvm nodes”

/sbin/lvm vgscan –mknodes

echo “enabling swap”

swapon /dev/vg/swap

Don’t forget to make this script executable too.

chmod u+x 40_fixlvmnodes.start

Be sure to update your /etc/fstab with your root and swap filesystems with the appropriate device paths. Mine looks like this.

/dev/vg/root / ext4 noatime 0 1

/dev/vg/swap none swap sw 0 0

Additional LVM usage

It is useful to become more familiar with lvm as it can be needed if you have to make any changes. For example when I did this on my new laptop I had created the root logical volume too small. It was using only 172G leaving over 500G unallocated! Using lvextend you can add unallocated space to a logical volume provided the physical volume can accommodate it.

lvextend -L+500G /dev/vg/root

Using lvextend I was able to use the full free space for my root partition as I had originally intended. The filesystem used for my root partition is ext4. In order for this already existing filesystem to see the available space I had to expand the filesystem as well.

I was able to do this, after resizing the logical volume above, with the following.

resize2fs /dev/mapper/vg-root

Keep in mind I did this from my livecd so the filesystem was not mounted during these operations. I’ve read that ext4 can be resized during runtime however I prefer not to chance potential filesystem corruption.

Once this was done I just rebooted and verified that my root partition was as large as it should be. All was good.

Final notes on full disk encryption

Other notes are that this is not entirely full disk encryption. The boot partition is obviously left unencrypted. If you truly want your entire disk to be encrypted you would have to perform the same operations but for all things involving the /boot partition you would use a USB drive of some kind. You will need this USB disk to boot your system. This offers more protection but managing a physical item is overkill for me. I just want to mention it in case someone is interested in doing this.

Now your root and swap partitions are fully encrypted at rest! Once your system is on however the disk is obviously unencrypted so disk encryption is only really useful “at rest”. This means if you shut down your system your content is safe. However once you boot up your filesystem is available if you are, say, nabbed while your system is on. In addition to this your crypto key is in memory at a probably known location (cryptsetup/dm-crypt are open source afterall). Its unlikely you will be in a scenario where this matters as only feds and those with some fun tools can make use of this information. I just want to be complete with this article so you are more aware. Knowing the ins and outs of security is very important.

That said, enjoy!

BIND DNSSEC Guide – DNSSEC deployment guide for BIND Version 1.1


BIND DNSSEC Guide

Abstract

This is version 1.1 of the DNSSEC deployment guide for BIND.

BIND is open source software that implements the Domain Name System (DNS) protocols for the Internet. It is a reference implementation of those protocols, but it is also production-grade software, suitable for use in high-volume and high-reliability applications.

Domain Name System Security Extensions (DNSSEC) extends standard DNS to provide a measure of security; it proves that the data comes from the official source and has not been modified in transit.

ISC BIND supports the full DNSSEC standard.


Table of Contents

Preface
1. Organization
2. Acknowledgement
1. Introduction
1.1. Who Should Read this Guide?
1.2. Who May Not Want to Read this Guide?
1.3. What is DNSSEC?
1.4. What does DNSSEC Add to DNS?
1.5. How Does DNSSEC Change DNS Lookup?
1.5.1. Chain of Trust
1.6. Why is DNSSEC Important? (Why Should I Care?)
1.7. How does DNSSEC Change My Job as a DNS Administrator?
2. Getting Started
2.1. Software Requirement
2.1.1. BIND Version
2.1.2. DNSSEC Support in BIND
2.1.3. System Entropy
2.2. Hardware Requirement
2.2.1. Recursive Server Hardware
2.2.2. Authoritative Server Hardware
2.3. Network Requirements
2.4. Operational Requirements
2.4.1. Parent Zone
2.4.2. Security Requirements
3. Validation
3.1. Easy Start Guide for Recursive Servers
3.2. How To Test Recursive Server (So You Think You Are Validating)
3.2.1. Using Web-based Tools to Verify
3.2.2. Using dig to Verify
3.2.3. Using delv to Verify
3.2.4. Verifying Protection from Bad Domain Names
3.2.5. How Do I know I Have a Validation Problem?
3.3. Validation Easy Start Explained
3.3.1. dnssec-validation
3.3.2. How Does DNSSEC Change DNS Lookup (Revisited)?
3.3.3. How are Answers Verified?
3.4. Trust Anchors
3.4.1. How Trust Anchors are Used
3.4.2. Trusted Keys and Managed Keys
3.5. What’s EDNS All About (And Why Should I Care)?
3.5.1. EDNS Overview
3.5.2. EDNS on DNS Servers
3.5.3. Support for Large Packets on Network Equipment
3.5.4. Wait… DNS Uses TCP?
4. Signing
4.1. Easy Start Guide for Signing Authoritative Zones
4.1.1. Generate Keys
4.1.2. Reconfigure BIND
4.1.3. Verification
4.1.4. Upload to Parent Zone
4.1.5. So… What Now?
4.1.6. Your Zone, Before and After DNSSEC
4.2. How To Test Authoritative Zones (So You Think You Are Signed)
4.2.1. Look for Key Data in Your Zone
4.2.2. Look for Signatures in Your Zone
4.2.3. Examine the Zone File
4.2.4. Check the Parent
4.2.5. External Testing Tools
4.3. Signing Easy Start Explained
4.3.1. Generate Keys Explained
4.3.2. Reconfigure BIND Explained
4.4. Working with Parent Zone
4.4.1. DS Record Format
4.4.2. DNSKEY Format
4.4.3. Trusted Key Format
4.4.4. What if My Parent Zone Doesn’t Support DNSSEC?
4.5. Using NSEC3
4.6. Maintenance Tasks
4.6.1. ZSK Rollover
4.6.2. KSK Rollover
5. Basic Troubleshooting
5.1. Query Path
5.2. Visible Symptoms
5.3. Logging
5.3.1. BIND DNSSEC Debug Logging
5.4. Common Problems
5.4.1. Security Lameness
5.4.2. Incorrect Time
5.4.3. Invalid Trust Anchors
5.4.4. Unable to Load Keys
5.5. NSEC3 Troubleshooting
5.6. Troubleshooting Example
6. Advanced Discussions
6.1. Key Generation
6.1.1. Can I Use the Same Key Pair for Multiple Zones?
6.1.2. Do I Need Separate ZSK and KSK?
6.1.3. Which Algorithm?
6.1.4. Key Sizes
6.2. Proof of Non-Existence (NSEC and NSEC3)
6.2.1. NSEC
6.2.2. NSEC3
6.2.3. NSEC or NSEC3?
6.3. Key Storage
6.3.1. Public Key Storage
6.3.2. Private Key Storage
6.3.3. Hardware Security Modules (HSM)
6.4. Key Management
6.4.1. Key Rollovers
6.4.2. Key Management and Metadata
6.4.3. How Long Do I Wait Before Deleting Old Data?
6.4.4. Emergency Key Rollovers
6.4.5. DNSKEY Algorithm Rollovers
6.5. Other Topics
6.5.1. DNSSEC and Dynamic Updates
6.5.2. DNSSEC and Inline Signing
6.5.3. DNSSEC Look-aside Validation (DLV)
6.5.4. DNSSEC on Private Networks
6.5.5. Introduction to DANE
6.6. Disadvantages of DNSSEC
7. Recipes
7.1. Inline Signing Recipes
7.1.1. Master Server Inline Signing Recipe
7.1.2. “Bump in the Wire” Inline Signing Recipe
7.2. Rollover Recipes
7.2.1. ZSK Rollover Recipe
7.2.2. KSK Rollover Recipe
7.3. NSEC and NSEC3 Recipes
7.3.1. Migrating from NSEC to NSEC3
7.3.2. Migrating from NSEC3 to NSEC
7.3.3. Changing NSEC3 Salt Recipe
7.3.4. NSEC3 Optout Recipe
7.4. Reverting to Unsigned Recipe
7.5. Self-signed Certificate Recipe
8. Commonly Asked Questions

List of Figures

1.1. DNSSEC Validation 12 Steps
3.1. DNSSEC Web-based Tests
3.2. Signature Generation
3.3. Signature Verification
3.4. DNSSEC Validation with .gov Trust Anchor
4.1. Verisign DNSSEC Debugger
4.2. DNSViz
4.3. Sec Spider
5.1. Query Path
7.1. Inline Signing Recipe #1
7.2. Inline Signing Scenario #2
7.3. Upload DS Record Step #1
7.4. Upload DS Record Step #2
7.5. Upload DS Record Step #3
7.6. Upload DS Record Step #4
7.7. Upload DS Record Step #5
7.8. Upload DS Record Step #6
7.9. Remove DS Record Step #1
7.10. Remove DS Record Step #2
7.11. Remove DS Record Step #3
7.12. Revert to Unsigned Step #1
7.13. Revert to Unsigned Step #2
7.14. Revert to Unsigned Step #3
7.15. Revert to Unsigned Step #4
7.16. Browser Certificate Warning
7.17. DNSSEC TLSA Validator

List of Tables

4.1. ZSK KSK Comparison
6.1. Key Metadata Comparison

Preface

Table of Contents

1. Organization
2. Acknowledgement

1. Organization

This document provides introductory information on how DNSSEC works, how to configure BIND to support some common DNSSEC features, as well as some basic troubleshooting tips. The chapters are organized as such:

Chapter 1, Introduction covers the intended audience for this document, assumed background knowledge, and a basic introduction to the topic of DNSSEC.

Chapter 2, Getting Started covers various requirements that are needed before implementing DNSSEC, such as software versions, hardware capacity, network requirements, and security changes.

Chapter 3, Validation walks through setting up a validating resolver, more information on the validation process, as well as examples of using tools to verify the resolver is validating answers.

Chapter 4, Signing walks through setting up a basic signed authoritative zone, explains the relationship with the parent zone, and on-going maintenance tasks.

Chapter 5, Basic Troubleshooting provides some tips on how to analyze and diagnose DNSSEC-related problems.

Chapter 6, Advanced Discussions covers several topics, from key generation, key storage, key management, NSEC and NSEC3, to disadvantages of DNSSEC.

Chapter 7, Recipes provides several working examples of common solutions, with step-by-step details.

Chapter 8, Commonly Asked Questions lists some commonly asked questions and answers about DNSSEC.

2. Acknowledgement

This document is originally authored by Josh Kuo of DeepDive Networking. He can be reached at <>

Thanks to the following individuals (in no particular order) who have helped in completing this document: Jeremy C. Reed, Heidi Schempf, Stephen Morris, Jeff Osborn, Vicky Risk, Jim Martin, Evan Hunt, Mark Andrews, Michael McNally, Kelli Blucher, Chuck Aurora, Francis Dupont, and Rob Nagy.

Special thanks goes to Cricket Liu and Matt Larson for their selflessness in knowledge sharing.

Thanks to all the reviewers and contributors, including: John Allen, Jim Young, Tony Finch, Timothe Litt, and Dr. Jeffry A. Spain.

The sections on key rollover and key timing meta data is borrowed heavily from the Internet Engineering Task Force draft titled “DNSSEC Key Timing Considerations” by S. Morris, J. Ihren, J. Dickinson, and W. Mekking. For more recent details, see “DNSSEC Key Rollover Timing Considerations”.

The recipe for TLSA self-signed certificate is based on the work of “A Step-by-Step guide for implementing DANE with a Proof of Concept” by Sandoche Balakrichenan, Stephane Bortzmeyer, and Mohsen Souissi (April 15, 2013) .

Icons made by Freepik and SimpleIcon from http://www.flaticon.com, licensed under Creative Commons BY 3.0 .

Chapter 1. Introduction

1.1. Who Should Read this Guide?

This guide is intended to be an introduction to DNSSEC for the DNS administrator who is comfortable working with the existing BIND and DNS infrastructure. He or she might be curious about DNSSEC, but has not had the time to read up about what DNSSEC is (or is not), whether or not DNSSEC should be a part of her or his environment, and what it means to deploy it in the field.

This guide provides basic information on how to configure DNSSEC using BIND9. Readers are assumed to have basic working knowledge of the Domain Name System (DNS) and related network infrastructure, such as concepts of TCP/IP. In-depth knowledge of DNS and TCP/IP is not required. The guide assumes no prior knowledge of DNSSEC or related technology such as public key cryptography.

1.2. Who May Not Want to Read this Guide?

If you are already operating a DNSSEC-signed zone, you may not learn much from the first half of the document, and you may want to start with Chapter 6, Advanced Discussions. If you want to learn about details of the protocol extension, such as data fields and flags, or the new record types, this document can help you get started but it won’t include all the technical details. If you are experienced in DNSSEC, you may find some of the concepts in this document to be overly simplified for your taste, and some details may be purposely omitted at times for illustration. If you administer a large or complex BIND environment, this guide may not provide enough information for you, as it is intended to provide the most basic, generic working examples. If you are a TLD operator, administer zones in .gov or .mil, this guide can help you get started, but does not provide enough details to serve all of your needs. If your DNS environment uses DNS products other than BIND, or in addition to, this document may provide some background or overlapping information, but you should check each product’s vendor documentation for specifics. Finally, deploying DNSSEC on internal or private networks is not covered in this document, with the exception of a brief discussion in Section 6.5.4, “DNSSEC on Private Networks”.

1.3. What is DNSSEC?

The Domain Name System (DNS) was designed in a day and age when the Internet was a friendly and trusting place. The protocol itself provides little protection against malicious or forged answers. DNS Security Extensions (DNSSEC) addresses this need, by adding digital signatures into DNS data, so each DNS response can be verified for integrity (message did not change during transit) and authenticity (sender is really the sender, not an impostor). In the ideal world when DNSSEC is fully deployed, every single DNS answer can be validated and trusted.

DNSSEC does not provide a secure tunnel; it does not encrypt or hide DNS data. It operates independently of an existing Public Key Infrastructure (PKI). It does not need SSL certificates or shared secrets. It was designed with backwards compatibility in mind, and can be deployed without impacting “old” insecure domain names.

DNSSEC is deployed on the three major components of the DNS infrastructure:

  • Recursive Server: People use recursive servers to lookup external domain names such http://www.example.com. Operators of recursive servers need to enable DNSSEC validation. With validation enabled, recursive servers will carry out additional tasks on each DNS response they received to ensure its authenticity.
  • Authoritative Server: People who publish DNS data on their name servers need to sign that data. This entails creating additional resource records, and publishing them to parent domains where necessary. With DNSSEC enabled, authoritative servers will respond to queries with additional DNS data, such as digital signatures and keys, in addition to the standard answers.
  • Application: This component lives on every client machine, from web server to smart phones. This includes resolver libraries on different Operating Systems, and applications such as web browsers.

In this guide, we will focus on the first two components, Recursive Server and Authoritative Server, and only lightly touch on the third component. We will look at how DNSSEC works, how to configure a validating resolver, how to sign DNS zone data, and other operational tasks and considerations.

1.4. What does DNSSEC Add to DNS?

Primer on Public Key Cryptography

Public Key Cryptography works on the concept of a pair of keys, one is made available to the world publicly, and one is kept in secrecy privately. Not surprisingly, they are known as public key and private key. If you are not familiar with the concept, think of it as a cleverly designed lock, where one key locks, and one key unlocks. In DNSSEC, we give out the unlocking public key to the rest of the world, while keeping the locking key private. To learn how this is used to secure DNS messages, take a look at Section 3.3.3, “How are Answers Verified?”.

DNSSEC introduces six new resource record types:

  • RRSIG (digital signature)
  • DNSKEY (public key)
  • DS (parent-child)
  • NSEC (proof of nonexistence)
  • NSEC3 (proof of nonexistence)
  • NSEC3PARAM (proof of nonexistence)

This guide will not dissect into the anatomy of each resource record type, the details are left for the readers to research and explore. Below is a short introduction on each of the new record types:

  • RRSIG: With DNSSEC enabled, just about every DNS answer (A, PTR, MX, SOA, DNSKEY, etc.) will come with at least one RRSIG, or resource record signature. These signatures are used by recursive name servers, also known as validating resolvers, to verify the answers received. To learn how digital signatures are generated and used, see Section 3.3.3, “How are Answers Verified?”.
  • DNSKEY: DNSSEC relies on public key cryptography for data authenticity and integrity. There are several keys used in DNSSEC, some private, some public. The public keys are published to the world as part of the zone data, and they are stored in the DNSKEY record type. In general, there are two categories of keys used in DNSSEC, Zone Signing Key (ZSK) is used to protect all zone data, and Key Signing Key (KSK) is used to protect other keys. We will talk about keys in Section 4.3.1, “Generate Keys Explained”, and again later in Section 6.1, “Key Generation”.
  • DS: One of the critical components of DNSSEC is that the parent zone can “vouch” for its child zone. DS record is verifiable information (generated from one of the child’s public keys) a parent zone keeps on its child as part of the chain of trust. To learn more about Chain of Trust, see Section 1.5.1, “Chain of Trust”.

The NSEC, NSEC3, and NSEC3PARAM resource records all deal with a very interesting problem: proving that something really does not exist. We will look at these record types in more detail in Section 6.2, “Proof of Non-Existence (NSEC and NSEC3) ”.

1.5. How Does DNSSEC Change DNS Lookup?

Traditional (insecure) DNS lookup is simple: a recursive name server receives a query from a client to lookup the name http://www.isc.org. The recursive name server tracks down the authoritative name server(s) responsible, sends the query to one of the authoritative name servers, and waits for the authoritative name server to respond with the answer.

With DNSSEC validation enabled, recursive name servers (validating resolver) will ask for additional resource records in its query, hoping the remote authoritative name servers will respond with more than just the answer to the query, but some proof to go along with the answer as well. If DNSSEC responses are received, the validating resolver will perform cryptographic computation to verify the authenticity (origin of the data) and integrity (data was not altered during transit) of the answers, and even ask the parent zone as part of the verification. It will repeat this process of get-key, validate, ask-parent, parent, and its parent, and its parent, all the way until the validating resolver reaches a key that it trusts. In the ideal, fully deployed world of DNSSEC, all validating resolvers only need to trust one key: the root key.

The following example shows the DNSSEC validating process of looking up the name http://www.isc.org at a very high level:

Figure 1.1. DNSSEC Validation 12 Steps

DNSSEC Validation 12 Steps
  1. Upon receiving a DNS query from a client to resolve http://www.isc.org, the validating resolver follows standard DNS protocol to track down the name server for isc.org, sends it a DNS query to ask for the A record ofhttp://www.isc.org. But since this is a DNSSEC-enabled resolver, the outgoing query has a bit set indicating it wants DNSSEC answers, hoping the name server who receives it speaks DNSSEC and can honor this secure request.
  2. isc.org name server is DNSSEC-enabled, and responds with the answer (in this case, an A record), and with a digital signature for verification purpose.
  3. The validating resolver needs to be able to verify the digital signature, and to do so it requires cryptographic keys. So it asks the isc.org name server for those keys.
  4. isc.org name server responds with the cryptographic keys (and digital signatures of the keys) used to generate the digital signature that was sent in #2. At this point, the validating resolver can use this information to verify the answers received in #2.

    Let’s take a quick break here and look at what we’ve got so far… how could we trust this answer? If a clever attacker had taken over the isc.org name server(s), or course she would send matching keys and signatures. We need to ask someone else to have confidence that we are really talking to the real isc.org name server. This is a critical part of DNSSEC: at some point, the DNS administrators at isc.org had uploaded some cryptographic information to its parent, .org, maybe it was a secure web submit form, maybe it was through an email exchange, or perhaps it was done in person. No matter the case, at some point, some verifiable information about the child (isc.org) was sent to the parent (.org), for safekeeping.

  5. The validating resolver asks the parent (.org) for the verifiable information it keeps on its child, isc.org.
  6. The verifiable information is sent from the .org server. At this point, validating resolver compares this to the answer it received in #4, and the two of them should match, proving the authenticity of isc.org.

    Let’s examine this process. You might be thinking to yourself, well, what if the clever attacker that took over isc.org also compromised the .org servers? Of course all this information would match! That’s why we will turn our attention now to the .org servers, interrogate it for its cryptographic keys, and move on one level up to .org‘s parent, root.

  7. The validating resolver asks .org authoritative name servers for its cryptographic keys, for the purpose of verifying the answers received in #6.
  8. .org name server responds with the answer (in this case, keys and signatures). At this point, validating resolver can verify the answers received in #6.
  9. The validating resolver asks root (.org‘s parent) for verifiable information it keeps on its child, .org.
  10. Root name server sends back the verifiable information it keeps on .org. The validating resolver now takes this information and uses it to verify the answers received in #8.

    So up to this point, both isc.org and .org check out. But what about root? What if this attacker is really clever and somehow tricked us into thinking she’s the root name server? Of course she would send us all matching information! So we repeat the interrogation process and ask for the keys from the root name server.

  11. Validating resolver asks root name server for its cryptographic keys in order to verify the answer(s) received in #10.
  12. Root name server sends keys, at this point, validating resolver can verify the answer(s) received in #10.

1.5.1. Chain of Trust

But what about the root server itself? Who do we go to verify root’s keys? There’s no parent zone for root. In security, you have to trust someone, and in the perfectly protected world of DNSSEC (we’ll talk about the current imperfect state later and ways to work around it), each validating resolver would only have to trust one entity, that is the root name server. The validating resolver would already have the root key on file (and we’ll talk about later how we got the root key file). So after answers in #12 are received, validating resolver takes the answer received and compare it to the key it already has on file, and these two should match. If they do, it means we can trust the answer from root, thus we can trust .org, and thus we can trust isc.org. This is known as “chain of trust” in DNSSEC.

We will revisit this 12-step process again later in Section 3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?” more technical details.

1.6. Why is DNSSEC Important? (Why Should I Care?)

You might be thinking to yourself: all this DNSSEC stuff sounds wonderful, but why should I care? Below are some reasons why you may want to consider deploying DNSSEC:

  1. Be a good netizen: By enabling DNSSEC validation (as described in Chapter 3, Validation) on your DNS servers, you’re protecting your users or yourself a little more by checking answers returned to you; by signing your zones (as described in Chapter 4, Signing), you are making it possible for other people to verify your zone data. As more people adopt DNSSEC, the Internet as a whole becomes more secure for everyone.
  2. Compliance: You may not even get a say whether or not you want to implement DNSSEC, if your organization is subject to compliance standards that mandate it. For example, the US government set a deadline back in 2008, to have all .gov sub domains signed by the December 2009 [1]. So if you operated a sub domain in .gov, you must implement DNSSEC in order to be compliant. One of the widely used compliance standards, PCI DSS for the payment card industry, has been rumored to list DNSSEC as a requirement or recommendation, as part of its on-going efforts to enhance security for online payment transactions. ICANN also requires that all new top-level domains support DNSSEC.
  3. Enhanced Security (C.Y.A.) : Okay, so the big lofty goal of “let’s be good” doesn’t appeal to you, and you don’t have any compliance standards to worry about . Here is a more practical reason why you should consider DNSSEC: in case of a DNS-based security breach, such as cache poisoning or domain hijacking, after all the financial and brand damage done to your domain name, you might be placed under scrutiny for any preventative measure that could have been put in place. Think of this like having your web site only available via HTTP but not HTTPS.
  4. New Features: DNSSEC brings not only enhanced security, but with that new level of security, a whole new suite of features. Once DNS can be trusted completely, it becomes possible to publish SSL certificates in DNS, or PGP keys for fully automatic cross-platform email encryption, or SSH fingerprints… People are still coming up with new features, but this all relies on a trust-worthy DNS infrastructure. To take a peek at these next generation DNS features, check out Section 6.5.5, “Introduction to DANE”.

1.7. How does DNSSEC Change My Job as a DNS Administrator?

With this protocol extension, some of the things you are used to in DNS will change. As the DNS administrator, you will have new maintenance tasks to perform on a regular basis (as described in Section 4.6, “Maintenance Tasks”); when there’s a DNS resolution problem, you have new troubleshooting techniques and tools to use (as described in Chapter 5, Basic Troubleshooting). BIND tries its best to make these things as transparent and seamless as possible. In this guide, we try to use the configuration examples that result in the least amount of work for DNS administrators.


[1] The Office of Management and Budget (OMB) for the US government published a memo in 2008 (www.whitehouse.gov/sites/default/files/omb/memoranda/fy2008/m08-23.pdf), requesting all .gov sub-domains to be DNSSEC signed by December 2009. This explains why .gov is the most deployed DNSSEC domain currently, with more than 80% sub domains signed.

Chapter 2. Getting Started

2.1. Software Requirement

2.1.1. BIND Version

The configuration examples given in this document requires BIND version 9.9 or newer. To check the version of named you have installed, use the -v switch as shown below:

# named -v
BIND 9.10.1

2.1.2. DNSSEC Support in BIND

All versions of BIND9 can support DNSSEC. The BIND software you are running most likely already supports DNSSEC as shipped. Run the command named -V to see what flags it was built with. If it was built with OpenSSL (--with-openssl), then it supports DNSSEC. Below is an example screenshot of running named -V:

$ named -V
BIND 9.10.1 <id:fe66c6b1> built by make with '--prefix=/opt/local'
'--mandir=/opt/local/share/man' '--with-openssl=/opt/local'
'--with-libxml2=/opt/local' '--without-libjson' '--enable-threads'
'--enable-ipv6' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -arch x86_64'
'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
'CPPFLAGS=-I/opt/local/include'
compiled by CLANG 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)
using OpenSSL version: OpenSSL 1.0.1i 6 Aug 2014
using libxml2 version: 2.9.1

If the BIND9 software you have does not support DNSSEC, it may be necessary to rebuild it from source or upgrade to a newer version.

2.1.3. System Entropy

If you plan on deploying DNSSEC to your authoritative server, you will need to generate cryptographic keys (Section 4.3.1, “Generate Keys Explained”). The amount of time it takes to generate the keys depends on the source of randomness, or entropy, on your systems. On some systems (especially virtual machines) with insufficient entropy, it may take much longer than one cares to wait to generate keys.

There are software packages, such as haveged for Linux, that provides additional entropy for your system. Once installed, they will significantly reduce the time needed to generate keys.

The more entropy there is, the better pseudo-random numbers you get, and stronger keys are generated. If you want or need high quality random numbers, take a look at Section 6.3.3, “Hardware Security Modules (HSM)” for some of the hardware-based solutions.

2.2. Hardware Requirement

2.2.1. Recursive Server Hardware

Enabling DNSSEC validation on a recursive server makes it a validating resolver. The job of a validating resolver is to fetch additional information that can be used to computationally verify the answer set. Below are the areas that should be considered for possible hardware enhancement for a validating resolver:

  1. CPU: a validating resolver executes cryptographic functions on many of the answers returned, this usually leads to increased CPU usage, unless your recursive server has built-in hardware to perform cryptographic computations.
  2. System memory: DNSSEC leads to larger answer sets, and will occupy more memory space.
  3. Network interfaces: although DNSSEC does increase the amount of DNS traffic overall, it is unlikely that you need to upgrade your network interface card (NIC) on the name server, unless you have some truly out-dated hardware.

One of the factors to consider is the destinations of your current DNS traffic. If your current users spend a lot of time visiting .gov web sites, then you should expect a bigger jump in all of the above categories when validation is enabled, because .gov is more than 80% signed. This means, more than 80% of the time, your validating resolver will be doing what is described in Section 1.5, “How Does DNSSEC Change DNS Lookup?”. However, if your users only care about resources in the .com domain, which as of this writing, is less than 0.1% signed, then your recursive name server is unlikely to experience significant load increase after enabling DNSSEC validation.

2.2.2. Authoritative Server Hardware

On the authoritative server side, DNSSEC is enabled on a zone-by-zone basis. When a zone is DNSSEC-enabled, it is also known as “signed”. Below are the areas that you should consider for possible hardware enhancements for an authoritative server with signed zones:

  1. CPU: DNSSEC signed zone requires periodic re-signing, which is a cryptographic function that is CPU intensive. If your DNS zone is dynamic or changes frequently, it also adds to higher CPU loads.
  2. System storage: A signed zone is definitely larger than an unsigned zone. How much larger? See Section 4.1.6, “Your Zone, Before and After DNSSEC” for a comparison example. Roughly speaking, you could expect your zone file to grow at least three times as large, usually more.
  3. System memory: Larger DNS zone files take up not only more storage space on the file system, but also more space when they are loaded into system memory.
  4. Network interfaces: While your authoritative name servers will begin sending back larger responses, it is unlikely that you need to upgrade your network interface card (NIC) on the name server, unless you have some truly out-dated hardware.

One of the factors to consider, but you really have no control over, is how many users who query your domain name have DNSSEC enabled. It is estimated in late 2014, that roughly 10% to 15% of the Internet DNS queries are DNSSEC aware. This translates to roughly 10% to 15% of the DNS queries for your domain will take advantage the additional security features, which result in the increased system load and possibly network traffic.

2.3. Network Requirements

From a network perspective, DNS and DNSSEC packets are very similar, DNSSEC packets are just bigger, which means DNS is more likely to use TCP. You should test for the following two items, to make sure your network is ready for DNSSEC:

  1. DNS over TCP: Verify network connectivity over TCP port 53, this may mean updating firewall policies or Access Control List (ACL) on routers. See Section 3.5.4, “Wait… DNS Uses TCP?” more details.
  2. Large UDP packets: Some network gears such as firewalls may make assumptions about the size of DNS UDP packets and reject DNS traffic that appears too big. You should verify that the responses your nameserver generates are being seen by the rest of the world. See Section 3.5, “What’s EDNS All About (And Why Should I Care)?” for more details.

2.4. Operational Requirements

2.4.1. Parent Zone

Before starting your DNSSEC deployment, check with your parent zone administrators to make sure they support DNSSEC. This may or may not be the same entity as your registrar. As you will see later in Section 4.4, “Working with Parent Zone”, a crucial step in DNSSEC deployment is to complete the parent-child trust relationship. If your parent zone does not support DNSSEC yet, contact them to voice your concern.

ICANN maintains a list of registrars who support DNSSEC:

https://www.icann.org/resources/pages/deployment-2012-02-25-en

2.4.2. Security Requirements

Some organizations may be subject to stricter security requirements than others. Check to see if your organization requires stronger cryptographic keys be generated and stored, or how often keys need to be rotated. The examples presented in this document are not intended for high value zones. We cover some of these security considerations in Chapter 6, Advanced Discussions.

Chapter 3. Validation

3.1. Easy Start Guide for Recursive Servers

This section provides the minimum amount of information to setup a working DNSSEC-aware recursive server, also known as a validating resolver. A validating resolver performs validation for each remote response received, following the chain of trust to verify the answers it receives are legitimate through the use of public key cryptography and hashing functions.

Once DNSSEC validation is enabled, any DNS response that does not pass the validation checks will result in the domain name not getting resolved (often a SERVFAIL status seen by the client). What this means for the DNS administrator is, if there is a DNSSEC configuration issue (sometimes outside of the administrator’s control), a specific name, or sometimes entire domains, may “disappear” from DNS, in that it becomes unreachable through that resolver. What this means for the end user is, name resolution is slow or fails altogether, or some parts of a URL will not load, or web browser will display some error message indicating the page cannot be displayed at all.

For example, if root name servers were misconfigured with the wrong information about .org, it could cause all validation for .org domains to fail. To the end users, it would appear that no one could get to any .org web sites.

You may not need to reconfigure your name server at all, since recent versions of BIND packages and distributions have been shipped with DNSSEC validation enabled by default. Before making any configuration changes, check whether or not you already have DNSSEC validation by following steps described in Section 3.2, “How To Test Recursive Server (So You Think You Are Validating)”.

Enabling DNSSEC validation on a BIND 9 recursive name server is easy, you only need one line of configuration in your configuration file:

options {
    dnssec-validation auto;
};

Restart named or use rndc reconfig, and your recursive server is now happily validating each DNS response. If this does not work for you, and you have already verified DNSSEC support as described in Section 2.1.2, “DNSSEC Support in BIND”, you most likely have some other network-related configurations that need to be adjusted, take a look at Section 2.3, “Network Requirements” to make sure your network is ready for DNSSEC.

DNSSEC is enabled by default for BIND, but this line enables automatic trust anchor configuration. To learn more about this configuration, please refer to Section 3.3, “Validation Easy Start Explained”.

3.2. How To Test Recursive Server (So You Think You Are Validating)

Okay, so now that you have reconfigured your recursive server and restarted it, how do you know that your recursive name server is actually verifying each DNS query? There are several ways to check, and we’ve listed a few suggestions below, starting with the easiest.

3.2.1. Using Web-based Tools to Verify

For most people, the simplest way to check if the recursive name server is indeed validating DNS queries, is to use one of the many web-based tools.

Configure your client computer to use the newly reconfigured recursive server for DNS resolution, and then you can use any one of these web-based tests to see if it is in fact validating answers DNS responses.

For example, opening the URL http://dnssectest.sidnlabs.nl/ in your web browser will show the following before (left) and after (right) DNSSEC validation is enabled:

Figure 3.1. DNSSEC Web-based Tests

DNSSEC Web-based Tests

3.2.2. Using dig to Verify

The web-based tools often employ JavaScript. If you don’t trust the JavaScript magic that the web-based tools rely on, you can take matters into your own hands and use a command line DNS tool to check your validating resolver yourself.

While nslookup is popular, partly because it comes pre-installed on most systems, it is not DNSSEC-aware. The Domain Information Groper (dig), on the other hand, fully supports the DNSSEC standard, and comes as a part of BIND. If you do not have dig already installed on your system, install it by downloading it from ISC’s web site. ISC provides pre-compiled Windows versions on its web site.

dig is a flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name server(s) that were queried. Most seasoned DNS administrators use dig to troubleshoot DNS problems because of its flexibility, ease of use, and clarity of output.

The example below shows using dig to query the name server 192.168.1.7 for the A record for http://www.isc.org if DNSSEC is disabled. The address 192.168.1.7 is only used as an example, you should replace this address with the actual address or host name of your recursive name server. Notice although we specifically used the +dnssec code line option, we do not see the DNSSEC OK (do) bit in the response, nor do we see any DNSSEC resource records.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline
; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20416
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.           IN  A

;; ANSWER SECTION:
www.isc.org.        60  IN  A   149.20.64.69

Below shows what the results look like querying the same server (192.168.1.7) after enabling DNSSEC validation. The exact same command is run, and this time notice three key differences:

  1. The presence of the Authenticated Data (ad) flag in the header
  2. The DNSSEC OK (do) flag indicating the recursive server is DNSSEC-aware
  3. An additional resource record of type RRSIG, with the same name as the A record.

The DNSSEC OK (do) flag tells us that the recursive server we are querying (192.168.1.7 in this example) is DNSSEC-aware. That its administrator has enabled DNSSEC on the name server to perform validation. The Authenticated Data (ad) flag tells us that the answer received has passed the validation process as described in Section 3.3.3, “How are Answers Verified?”. We can have confidence in the authenticity and integrity of the answer that http://www.isc.org really points to the IP address 149.20.64.69, and it was not a spoofed answer from a clever attacker.

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32472
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.       IN A

;; ANSWER SECTION:
www.isc.org.        4 IN A  149.20.64.69
www.isc.org.        4 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 3 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:40:04 CST 2014
;; MSG SIZE  rcvd: 223

3.2.3. Using delv to Verify

If you have BIND 9.10 or later, you can use Domain Entity Lookup & Validation (delv) to validate your setup. This program is similar to dig, but is specifically tailored for DNSSEC.

Without DNSSEC:

$ delv @192.168.1.7 www.isc.org. A
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

delv also comes with a handy +rtrace (trace resolver fetches) switch that shows a little more information on what was fetched:

$  delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; fetch: org/DS
;; no valid RRSIG resolving 'org/DS/IN': 192.168.1.7#53
;; no valid DS resolving 'www.isc.org/A/IN': 192.168.1.7#53
;; resolution failed: no valid DS

After enabling DNSSEC validation, re-running the exact same codes show us the following results:

$ delv @192.168.1.7 www.isc.org. A +multiline
; fully validated
www.isc.org.        60 IN A 149.20.64.69
www.isc.org.        60 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

And +rtrace shows all the glory of what records were fetched to validate this answer:

$ delv @192.168.1.7 www.isc.org +rtrace +multiline
;; fetch: www.isc.org/A
;; fetch: isc.org/DNSKEY
;; fetch: isc.org/DS
;; fetch: org/DNSKEY
;; fetch: org/DS
;; fetch: ./DNSKEY
; fully validated
www.isc.org.        19 IN A 149.20.64.69
www.isc.org.        19 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

3.2.4. Verifying Protection from Bad Domain Names

It is also important to make sure that DNSSEC is protecting you from domain names that fail to validate; such failures could be caused by attacks on your system, attempting to get it to accept false DNS information. Validation could fail for a number of reasons, maybe the answer doesn’t verify because it’s a spoofed response; maybe the signature was a replayed network attack that has expired; or maybe the child zone has been compromised along with its keys, and the parent zone’s information is telling us that things don’t add up. There is a domain name specifically setup to purposely fail DNSSEC validation, http://www.dnssec-failed.org. Prior to enabling DNSSEC validation, you should have no trouble visiting the URL http://www.dnssec-failed.org/ in your web browser:

And no problem resolving the domain name as shown below using dig:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28878
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.     IN  A

;; ANSWER SECTION:
www.dnssec-failed.org.  7200    IN  A   68.87.109.242
www.dnssec-failed.org.  7200    IN  A   69.252.193.191

;; Query time: 955 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:42:50 CST 2014
;; MSG SIZE  rcvd: 82

After DNSSEC validation is enabled, any attempt to loading the URL should result in some kind of “Sorry, this page cannot be displayed” error message from your web browser. And looking up this domain name using digshould result in SERVFAIL, as shown below:

$ dig @192.168.1.7 www.dnssec-failed.org. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46592
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org.     IN  A

;; Query time: 2435 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 17 07:44:56 CST 2014
;; MSG SIZE  rcvd: 50

3.2.5. How Do I know I Have a Validation Problem?

Since all DNSSEC validation failures result in a general SERVFAIL message, how do we know that it was related to validation in the first place? Fortunately, there is a flag to disable DNSSEC validation in dig, +cd (checking disable). When you’ve received a SERVFAIL message, re-run the query one more time, and throw in the +cd flag. If the query succeeds with +cd, but ends in SERVFAIL without it, then you know you are dealing with a validation problem.

$ dig @192.168.1.7 www.isc.org. A +cd

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33590
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.           IN  A

;; ANSWER SECTION:
www.isc.org.        30  IN  A   149.20.64.69

For more information on troubleshooting, please see Chapter 5, Basic Troubleshooting.

3.3. Validation Easy Start Explained

In Section 3.1, “Easy Start Guide for Recursive Servers”, we used one line of configuration to turn on DNSSEC validation, the act of chasing down signatures and keys, making sure they are authentic. Now we are going to take a closer look at what it actually does, and some other options.

3.3.1. dnssec-validation

options {
    dnssec-validation auto;
};

This auto line enables automatic DNSSEC trust anchor configuration using the managed-keys feature. In this case, no manual key configuration is needed. There are three possible choices for the dnssec-validationoption:

  • yes: DNSSEC validation is enabled, but a trust anchor must be manually configured. No validation will actually take place until you have manually configured at least one trusted key. This is the default.
  • no: DNSSEC validation is disabled, and recursive server will behave in the “old fashioned” way of performing insecure DNS lookups.
  • auto: DNSSEC validation is enabled, and a default trust anchor (included as part of BIND) for the DNS root zone is used.

Let’s discuss the difference between yes and auto. If you set it to yes (the default), the trust anchor will need to be manually defined and maintained using the trusted-keys statement in the configuration file; if you set it toauto (as shown in the example), then no further action should be required as BIND includes a copy[2] of the root key. When set to auto, BIND will automatically keep the keys (also known as trust anchors, which we will look at in Section 3.4, “Trust Anchors”) up-to-date without intervention from the DNS administrator.

We recommend auto unless you have a good reason for requiring a manual trust anchor. To learn more about trust anchors, please refer to Section 3.4.2, “Trusted Keys and Managed Keys”.

Note

dnssec-enable needs to be set to yes (default value is yes) in order for dnssec-validation to be effective.

3.3.2. How Does DNSSEC Change DNS Lookup (Revisited)?

So by now you’ve enabled validation on your recursive name server, and verified that it works. What exactly changed? In Section 1.5, “How Does DNSSEC Change DNS Lookup?” we looked at the very high level, simplified 12-steps of DNSSEC validation process. Let’s revisit that process now and see what your validating resolver is doing in more detail. Again, we are using the example to lookup the A record for the domain name http://www.isc.org(Figure 1.1, “DNSSEC Validation 12 Steps”):

  1. Validating resolver queries isc.org name servers for the A record of http://www.isc.org. This query has the DNSSEC OK (do) bit set to 1, notifying the remote authoritative server that DNSSEC answers are desired.
  2. The zone isc.org is signed, and its name servers are DNSSEC-aware, thus it responds with the answer to the A record query plus the RRSIG for the A record.
  3. Validating resolver queries for the DNSKEY for isc.org.
  4. isc.org name server responds with the DNSKEY and RRSIG records. The DNSKEY is used to verify the answers received in #2.
  5. Validating resolver queries the parent (.org) for the DS record for isc.org.
  6. .org name server responds with the DS and RRSIG records. The DS record is used to verify the answers received in #4.
  7. Validating resolver queries for the DNSKEY for .org.
  8. .org name server responds with DNSKEY and RRSIG. The DNSKEY is used to verify the answers received in #6.
  9. Validating resolver queries the parent (root) for the DS record for .org.
  10. Root name server responds with DS and RRSIG records. The DS record is used to verify the answers received in #8.
  11. Validating resolver queries for the DNSKEY for root.
  12. Root name server responds with DNSKEY and RRSIG. The DNSKEY is used to verify the answers received in #10.

After step #12, the validating resolver takes the DNSKEY received and compares to the key or keys it has configured, to decide whether or not the received key can be trusted. We will talk about these locally configured keys, or trust anchors, in Section 3.4, “Trust Anchors”.

As you can see here, with DNSSEC, every response includes not just the answer, but a digital signature (RRSIG) as well. This is so the validating resolver can verify the answer received, and that’s what we will look at in the next section, Section 3.3.3, “How are Answers Verified?”.

3.3.3. How are Answers Verified?

Note

Keep in mind as you read this section, that although words like encryption and decryption are used from time to time, DNSSEC does not provide you with privacy. Public key cryptography is used to provide data authenticity (who sent it) and data integrity (it did not change during transit), but any eavesdropper can still see your DNS requests and responses in clear text, even when DNSSEC is enabled.

So how exactly are DNSSEC answers verified? Before we can talk about how they are verified, let’s first see how verifiable information is generated. On the authoritative server, each DNS record (or message) is run through a hash function, then this hashed value is encrypted by a private key. This encrypted hash value is the digital signature.

Figure 3.2. Signature Generation

Signature Generation


When the validating resolver queries for the resource record, it receives both the plain-text message and the digital signature(s). The validating resolver knows the hash function used (listed in the digital signature record itself), so it can take the plain-text message and run it through the same hash function to produce a hashed value, let’s call it hash value X. The validating resolver can also obtain the public key (published as DNSKEY records), decrypt the digital signature, and get back the original hashed value produced by the authoritative server, let’s call it hash value Y. If hash values X and Y are identical, and the time is correct (more on what this means below), the answer is verified, meaning we know this answer came from the authoritative server (authenticity), and the content remained intact during transit (integrity).

Figure 3.3. Signature Verification

Signature Verification


Take the A record http://www.isc.org for example, the plain text is:

www.isc.org.        4 IN A  149.20.64.69

The digital signature portion is:

www.isc.org.        4 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

When a validating resolver queries for the A record http://www.isc.org, it receives both the A record and the RRSIG record. It runs the A record through a hash function (in this example, it would be SHA1 as indicated by the number 5, signifying RSA-SHA1) and produces hash value X. The resolver also fetches the appropriate DNSKEY record to decrypt the signature, and the result of the decryption is hash value Y.

But wait! There’s more! Just because X equals Y doesn’t mean everything is good. We still have to look at the time. Remember we mentioned a little earlier that we need to check if the time is correct? Well, look at the two highlighted timestamps in our example above, the two timestamps are:

  • Signature Expiration: 20141029233238
  • Signature Inception: 20140929233238

This tells us that this signature was generated UTC September 29th, 2014, at 11:32:38PM (20140929233238), and it is good until UTC October 29th, 2014, 11:32:38PM (20141029233238). And the validating resolver’s current system time needs to fall between these two timestamps. Otherwise the validation fails, because it could be an attacker replaying an old captured answer set from the past, or feeding us a crafted one with incorrect future timestamps.

If the answer passes both hash value check and timestamp check, it is validated, and the authenticated data (ad) bit is set, and response is sent to the client; if it does not verify, a SERVFAIL is returned to the client.

3.4. Trust Anchors

A trust anchor is a key that is placed into a validating resolver so that the validator can verify the results for a given request back to a known or trusted public key (the trust anchor). A validating resolver must have at least one trust anchor installed in order to perform DNSSEC validation.

3.4.1. How Trust Anchors are Used

In the section Section 3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?”, we walked through the DNSSEC lookup process (12 steps), and at the end of the 12 steps, a critical comparison happens: the key received from the remote server, and the key we have on file are compared to see if we trust it. The key we have on file is called a trust anchor, sometimes also known as trust key, trust point, or secure entry point.

The 12-step lookup process describes the DNSSEC lookup in the ideal world where every single domain name is signed and properly delegated, each validating resolver only needs to have one trust anchor, and that is the root’s public key. But there is no restriction that the validating resolver must only have one trust anchor. In fact, in the early stages of DNSSEC adoption, it is not unusual for a validating resolver to have more than one trust anchor.

For instance, before the root zone was signed (prior to the year 2010), some validating resolvers that wish to validate domain names in the .gov zone needed to obtain and install the key for .gov. A sample lookup process for http://www.fbi.gov would thus be only 8 steps rather than 12 steps that look like this:

Figure 3.4. DNSSEC Validation with .gov Trust Anchor

DNSSEC Validation with .gov Trust Anchor
  1. Validating resolver queries fbi.gov name server for the A record of http://www.fbi.gov.
  2. FBI’s name server responds with answer and RRSIG.
  3. Validating resolver queries FBI’s name server for DNSKEY.
  4. FBI’s name server responds with DNSKEY and RRSIG.
  5. Validating resolver queries .gov name server for DS record of fbi.gov.
  6. .gov name server responds with DS record and RRSIG for fbi.gov.
  7. Validating resolver queries .gov name server for DNSKEY.
  8. .gov name server responds with DNSKEY and RRSIG.

This all looks very similar, except it’s shorter than the 12-steps that we saw earlier. Once the validating resolver receives the DNSKEY file in #8, it recognizes that this is the manually configured trusted key (trust anchor), and never goes to the root name servers to ask for the DS record for .gov, or ask the root name servers for its DNSKEY.

In fact, whenever the validating resolver receives a DNSKEY, it checks to see if this is a configured trusted key, to decide whether or not it needs to continue chasing down the validation chain.

3.4.2. Trusted Keys and Managed Keys

So, as the resolver is validating, we must have at least one key (trust anchor) configured. How did it get here, and how do we maintain it?

If you followed the recommendation in Section 3.1, “Easy Start Guide for Recursive Servers”, by setting dnssec-validation to auto, then there is nothing you need to do. BIND already includes a default key (in the filebind.keys), that will automatically update itself. It looks something like this:

managed-keys {
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

You could, of course, decide to manage this key on your own by hand. First, you’ll need to make sure that your dnssec-validation is set to yes rather than auto:

options {
    dnssec-validation yes;
};

Then, download the root key manually from a trustworthy source, such as https://www.isc.org/bind-keys. Finally, take the root key you manually downloaded, and put it into a trusted-keys statement as shown below:

trusted-keys {
    . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
};

Looking back at the example in Section 3.4.1, “How Trust Anchors are Used”, if you wanted to explicitly trust .gov and only validate domain names under .gov, your trusted-keys statement would look something like this:

trusted-keys {
    gov. 257 3 8 "AQO8daaz7B+yshOfL60rytKd9aOSujgponEw3fwBMEC3
    /+e9XzHw2k+VKnbJTZ+QaVtpfUd1q9HKZIv/ck83Gl5T
    jYKE5jtUZ2kpEDZfVNGv6yx0smtWAXv1nCJS9ohnyOTd
    397eMojGDHqkEC+uojEScZheEkMxzgCZwDAs+/CSU7mS
    uHtCRZn19xlZUd5Gv7yDQ3mbOUwuy30oSk0z1Q5UUPpo
    ihOugIZHFX6Jk7NLiW2wlqfq9qhV4zj7TiBiJY0mCc4z
    HN8/aq2VKDHp2Na7mWzvKyTy+SYQkBQ/08LbPwj9YMc+
    uCzKL6sU/ObHv17EFhD8aPDftTHZvV9L+OZr";
};

As the name trusted-keys suggests, it is possible to have more than one key configured. You could also leverage Section 6.5.3, “DNSSEC Look-aside Validation (DLV)” as part of your trust-anchor management strategy.

While trusted-keys and managed-keys appear similar, there is an important difference: trusted-keys are always trusted, until they are deleted from named.conf; managed-keys (specifically, initial-key, which is the only supported type currently) are only trusted once: for as long as it takes to load the managed key database and start the key maintenance process.

Note

Remember, if you choose to manage the keys on your own, whenever the key changes, the configuration needs to be updated manually. Failing to do so will result in breaking nearly all DNS queries for the sub domain of the key. So if you are manually managing .gov, all domain names in the .gov space may become unresolvable; if you are manually managing the root key, you could break all DNS requests made to your recursive name server if the root key is incorrect.

3.5. What’s EDNS All About (And Why Should I Care)?

3.5.1. EDNS Overview

Traditional DNS responses are typically small in size, less than 512 bytes, that fits nicely into a small UDP packet. Extension mechanism for DNS (EDNS, or EDNS(0)) gives us a mechanism to send DNS data in larger packets over UDP. In order to support EDNS, both the DNS server and the network need to be properly prepared to support the larger packet size and multiple fragments.

This is important for DNSSEC, since DNSSEC responses are larger than traditional DNS. If DNS servers and network environment cannot support large UDP packets, it will cause retransmission over TCP, or the larger UDP responses will be discarded. Users will likely experience slow DNS resolution or unable to resolve certain names at all.

Note that EDNS applies whether or not you are validating DNSSEC because BIND has DNSSEC enabled by default.

Please see Section 2.3, “Network Requirements” for more information on what DNSSEC expects from the network environment.

3.5.2. EDNS on DNS Servers

BIND has been shipped with EDNS enabled by default for over a decade, and the UDP packet size is set to a maximum of 4096 bytes. So as the DNS administrator, there should not be any re-configuration needed. You can use dig to verify that your server supports EDNS and the UDP packet size it is allowing as follows:

$ dig @192.168.1.7 www.isc.org. A +dnssec +multiline

; <<>> DiG 9.10.0-P2 <<>> @192.168.1.7 www.isc.org. A +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63266
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.       IN A

;; ANSWER SECTION:
www.isc.org.        23 IN A 149.20.64.69
www.isc.org.        23 IN RRSIG A 5 3 60 (
                20141029233238 20140929233238 4521 isc.org.
                DX5BaGVd4KzU2AIH911Kar/UmdmkARyPhJVLr0oyPZaq
                5zoobGqFI4efvzL0mcpncuUg3BSU5Q48WdBu92xinMdb
                E75zl+adgEBOsFgFQR/zqM3myt/8SngWm4+TQ3XFh9eN
                jqExHZZuZ268Ntlxqgf9OmKRRv8X8YigaPShuyU= )

;; Query time: 7 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Fri Oct 03 16:31:33 CST 2014
;; MSG SIZE  rcvd: 223

There is a helpful testing tool available (provided by DNS-OARC) that you can use to verify resolver behavior regarding EDNS support: https://www.dns-oarc.net/oarc/services/replysizetest/

So you made sure your name servers have EDNS enabled. That should be the end of the story, right? Unfortunately, EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is negotiated between each pair of hosts in a DNS resolution process, which in turn means if one of your upstream name servers (for instance, your ISP’s recursive name server that you forward to) does not support EDNS, you will still experience packet fragmentation.

3.5.3. Support for Large Packets on Network Equipment

Okay, so both your recursive name server and your ISP’s name servers support EDNS, we are all good here, right? Not so fast. As these large packets have to traverse through the network, the network infrastructure itself must allow them to pass.

When data is physically transmitted over a network, it has to be broken down into chunks. The size of the data chunk is known as Maximum Transmission Units (MTU), and it can be different from network to network. IP fragmentation occurs when a large data packet needs to be broken down into smaller chunks so that each chunk is smaller than the MTU, and these smaller chunks need to be reassembled back into the large data packet. IP fragmentation is not necessarily a bad thing, it most likely occurs on your network today.

Some network equipment, such as firewalls, may make assumptions about DNS traffic. One of these assumptions may be how large each DNS packet is. When a firewall sees a larger DNS packet than it expects, it either rejects the large packet or drops its fragments because the firewall thinks it’s an attack. This configuration probably didn’t cause problems in the past since traditional DNS packets are usually pretty small in size. However, with DNSSEC, these configurations need to be updated, since DNSSEC traffic regularly exceeds 1500 bytes (a common MTU value). If the configuration is not updated to support larger DNS packet size, it will often result in the larger packets being rejected, and to the end user it looks like the queries go un-answered. Or in the case of fragmentation, only a part of the answer made it to the validating resolver, and your validating resolver may need to re-ask the question again and again, creating the appearance “DNS/network is really slow” for the end users.

And while you’re updating configuration on your network equipment, make sure TCP port 53 is also allowed for DNS traffic.

3.5.4. Wait… DNS Uses TCP?

Yes. DNS uses TCP port 53 as a fallback mechanism, when it cannot use UDP to transmit data. This has always been the case even long before DNSSEC arrived at the scene. Traditional DNS relies on TCP 53 for operations such as zone transfer. The use of DNSSEC, or DNS with IPv6 records such as AAAA, increases the chance that DNS data will be transmitted on TCP.

Due to the increased packet size, DNSSEC may fall back to TCP more often then traditional (insecure) DNS. If your network is blocking or filtering TCP port 53 today, you may already experience instability with DNS resolution before deploying DNSSEC.


[2] BIND technically includes two copies of the root key, one is in bind.keys.h and is built into the executable, and one is in bind.keys as a managed-keys statement. The two copies of the key are identical.

Chapter 4. Signing

4.1. Easy Start Guide for Signing Authoritative Zones

This section provides the minimum amount of information to setup a working DNSSEC-enabled authoritative name server. A DNSSEC-enabled zone (or “signed” zone) contains additional resource records that are used to verify the authenticity of its zone information.

To convert a traditional (insecure) DNS zone to a secure one, we need to create various additional records (DNSKEY, RRSIG, NSEC or NSEC3), and upload verifiable information (such as DS record) to the parent zone to complete the chain of trust. For more information about DNSSEC resource records, please see Section 1.4, “What does DNSSEC Add to DNS?”.

Note

In this chapter we assume all configuration files, key files, and zone files are stored in /etc/bind. And most of the times we show examples of running various commands as the root user. This is arguably not the best setup, but we don’t want to distract you from what’s important here: learning how to sign a zone. There are many best practices for deploying a more secure BIND installation, with techniques such as jailed process and restricted user privileges, but we are not going to cover any of those in this document. We are trusting you, a responsible DNS administrator, to take the necessary precautions to secure your system.

For our examples below, we will be working with the assumption that there is an existing insecure zone example.com that we will be converting to a secure version.

4.1.1. Generate Keys

Everything in DNSSEC centers around keys, and we will begin by generating our own keys. In our example, we are keeping all the keys for example.com in its own directory, /etc/bind/keys/example.com.

# mkdir -p /etc/bind/keys/example.com
# cd /etc/bind/keys/example.com
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++ 
Kexample.com.+008+17694
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++ 
Kexample.com.+008+06817

This generated four key files in /etc/bind/keys/example.com, and the only one we care about for now is the KSK key, Kexample.com.+008+06817.key. Remember this file name: we will need it again shortly. Make sure these files are readable by named.

Refer to Section 2.1.3, “System Entropy” for information on how you could speed this process up.

4.1.2. Reconfigure BIND

Below is a very simple named.conf, in our example environment, this file is /etc/bind/named.conf. The lines you most likely need to add are in bold.

options {
    directory "/etc/bind";
    recursion no;
    minimal-responses yes;
};

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
};

When you are done updating the configuration file, tell named to reload:

# rndc reload
server reload successful

4.1.3. Verification

Your zone is now signed. Before moving on to the next step of coordinating with your parent zone, let’s make sure everything looks good using delv. What we want to do is to simulate what a validating resolver would check, by telling delv to use a specific trust anchor.

First of all, we need to make a copy of the key Kexample.com.+008+06817.key for editing:

# cp /etc/bind/keys/example.com/Kexample.com.+008+06817.key /tmp/example.key

The original key file looks like this (actual key shortened for display, and comments omitted):

# cat /etc/bind/keys/example.com/Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

We want to edit the copy to the be the trusted-keys format, so that it looks like this:

# cat /tmp/example.key
trusted-keys {
    example.com. 257 3 8 "AwEAAcWDps...lM3NRn/G/R";
};

Now we can run the delv command and point it to using this trusted-key file to validate the answer it receives from the authoritative name server 192.168.1.13:

$ delv @192.168.1.13 -a /tmp/example.key +root=example.com example.com. SOA +multiline
; fully validated
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014112007 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20150107091559 20141208081559 17694 example.com.
                LwG0rLOm9Q1Lu9bgIz1O+PTCwcCSs1Ev8Eqkqqd3gUJK
                qo0FSVv//axNVJFH2Lz8VLgFypD8xARWj1XQBD/9DIf6
                A3ncnrFymKdKze+2ghvTUxpwqctK4RF66mhu93e33+Ir
                QJVJgdHJVHudQWICA1AbIBYYzLGkKlp7JAJcgBM= )

4.1.4. Upload to Parent Zone

Everything is done on our name server, now we need to generate some information to be uploaded to the parent zone to complete the chain of trust. The formats and the upload methods are actually dictated by your parent zone’s administrator, so contact your registrar or parent zone administrator to find out what the actual format should be, and how to deliver or upload the information to your parent zone.

What about your zone between the time you signed it and the time your parent zone accepts the upload? Well, to the rest of the world, your zone still appears to be insecure. That is because when a validating resolver attempts to validate your domain name, it will eventually come across your parent zone, and your parent zone will indicate that you are not yet signed (as far as it knows). The validating resolver will then give up attempting to validate your domain name, and fall back to the insecure DNS. Basically, before you complete this final step with your parent zone, your zone is still insecure.

Note

Before uploading to your parent zone, verify that your newly signed zone has propagated to all of your name servers (usually zone transfers). If some of your name servers still have unsigned zone data while the parent tells the world it should be signed, validating resolvers around the world will not resolve your domain name.

Here are some examples of what you may upload to your parent zone, actual keys shortened for display. Note that no matter what formats may be required, the end result will be the parent zone publishing DS record(s) based on the information you upload. Again, contact your parent zone administrator(s) to find out what is the correct format for you.

  1. DS Record Format: example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
  2. DNSKEY Format: example.com. 172800 IN DNSKEY 257 3 8 (AwEAAcjGaU...zuu55If5) ; key id = 06817
  3. Trusted Key Format: "example.com." 257 3 8 "AwEAAcjGaU...zuu55If5";

The DS record format may be generated using the dnssec-dsfromkey tool which is covered in Section 4.4.1, “DS Record Format”. For more details and examples on how to work with your parent zone, please seeSection 4.4, “Working with Parent Zone”

4.1.5. So… What Now?

Congratulations, your zone is signed, and parent zone has accepted your upload. Your zone is now officially DNSSEC-enabled. If you have any slave name servers that perform zone transfers from you, they will receive the new DNSSEC-enabled zone data. What happens next? Well, there are a few maintenance tasks you need to do on a regular basis, which you can find in Section 4.6, “Maintenance Tasks”. As for updating your zone file, you can continue to update them the same way you have been prior to signing your zone, the normal work flow of editing zone file and using the rndc command to reload the zone still works the same, and although you are editing the unsigned version of the zone, BIND will generate the signed version automatically.

Curious as to what all these commands did to your zone file? Read on to Section 4.1.6, “Your Zone, Before and After DNSSEC” and find out. If you are interested in how you can roll this out to your existing master and slave name servers, check out Section 7.1, “Inline Signing Recipes” in Chapter 7, Recipes.

4.1.6. Your Zone, Before and After DNSSEC

In the previous section Section 4.1, “Easy Start Guide for Signing Authoritative Zones”, we provided the minimal amount of information to essentially convert a traditional DNS zone into a DNSSEC-enabled zone. This is what the zone looked like before we started:

$ dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014102100 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN NS ns1.example.com.
ftp.example.com.    600 IN A 192.168.1.200
ns1.example.com.    600 IN A 192.168.1.1
web.example.com.    600 IN CNAME www.example.com.
www.example.com.    600 IN A 192.168.1.100

Below shows the test zone example.com after we have reloaded the server configuration. As you can see, the zone grew in size, and the number of records multiplied:

# dig @192.168.1.13 example.com. AXFR +multiline +onesoa

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. AXFR +multiline +onesoa
; (1 server found)
;; global options: +cmd
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014102104 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        300 IN RRSIG NSEC 8 2 300 (
                20141126120153 20141027112239 60798 example.com.
                U1je2BEXY7S/u4An8sKEp2Cb8b90+9mNBoFb9nXgkTvC
                cJkT/4OIUIaO7EbsIASmlzjDwJEKSO/nPDFg3y6tsR0m
                GT7H7AYAouwBhUlIrDrGQpxqRLJXA1kPkxboX4M2JGx4
                rBcBsN/7lG5CGbjtLW3PMnJRELE5fBJBLZM1KLo= )
example.com.        300 IN NSEC ftp.example.com. NS SOA RRSIG NSEC DNSKEY TYPE65534
example.com.        600 IN RRSIG NS 8 2 600 (
                20141126115318 20141027112239 60798 example.com.
                TGC1gAksxHHDoltjJ8ETJ9qdr5MzFjA05vEllSNWBFe7
                O71Payf8o4MISHNeUoZpu7Ys4zBiTRLqUaLeI0oSEnzM
                r2QJkrfUHl1k8D/wCWApEUhMa1GxLIKMsEfgd3D5nK52
                6LAVNihx5BKC1YxuYZXhhBMYQm7bIlUXFvxl3uE= )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20141126122239 20141027112239 60798 example.com.
                0ntLprFpg9bKWs5ArGvpZq8uFa9QPEfl6bOmfIwbNnEp
                9PgBS97icRs27JDgIXGM4dWxXiPVX6sZ8jFulSp2mi2v
                4dhtqMfb4S/rfxSmCphIz5PA+bngKSr5fhRI6tTM8fW1
                l5V3zfKCPFracE0CgdcWIt0xViEs56Axj942f5w= )
example.com.        0 IN RRSIG TYPE65534 8 2 0 (
                20141126120153 20141027112239 60798 example.com.
                Sv+7vfHXz4zlLSEuWs5Bt5boqSDVCK2GcOgAzVXnW9/0
                zgk3v8VwSXRTRnwdsvl3SK6YsM9S/HNXk32AQs2PjXf4
                2/cmv6VCOGSVGin/L5k4KWjpy0ESV2iY0hIIyeXWqUdB
                ZUCu1+2GhHiA5+gKODn/8sg6x04g+lZe6wuhU44= )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20141126122239 20141027112239 45319 example.com.
                F2vrBJqvloP5yNE6X1+b1XJ4gY6DlH1oyJz6pSULmGgQ
                FFztyrCJoV4MI6TeFRXJKLTePewjcTzKlaRKJHZRElcM
                QaClWr6RdZ2Uc1fFOBgYocrDZtGWdTVg7XCiLJ/ubrDH
                7et9rSexmKEwI44T4Vf7w3e+kUQSzMBGfA9Z5Q8WnnBW
                IDn4QFqRx0B02bVLV4giJbVp649ukIApVoHSpJvhrWq8
                eSSdP2ojymzr4gAuQZzmZUJnxp7Q3ktuQgIokhLG4FDH
                /O9qnhnOkUZFsxbBaDYVn5TIl1Kkmn3LH98JQE0z8a7D
                WfqAPAFy0rKHkvyOA8FlimDW09OYeJS00A== )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20141126122239 20141027112239 60798 example.com.
                PoUdallJO0ZF3iFmRoGoKh/iLAJVn52ABVEVku9LK34C
                oh4Y29rgK4jd3DwxU7zDLadVs0Fo3JFHp2jdYCEm03BS
                XE6d0cijZP5aFt8rO/grO/qbkdv+ScEi1kOhCKcvt3Kg
                1mXhiZt4Jx3LeisUpD9mGa+m9ehcPYlAHPKoZMg= )
example.com.        0 IN TYPE65534 \# 5 ( 08B1070001 )
example.com.        0 IN TYPE65534 \# 5 ( 08ED7E0001 )
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAfbc/0ESumm1mPVkm025PfHKHNYW62yx0wyLN5LE
                4DifN6FzIVSKSGdMOdq+z6vFGxzzjPDz7QZdeC6ttIUA
                Bo4tG7dDrsWK+tG5cm4vuylsEVbnnW5i+gFG/02+RYmZ
                ZT9AobXB5bVjfXl9SDBgpBluB35WUCAnK9WkRRUS08lf
                ) ; ZSK; alg = RSASHA256; key id = 60798
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAb4N53kPbdRTAwvJT8OYVeVhQIldwppMy7KBJ+8k
                Uggx2PU3yP/qlq4Zjl0MMmqRiJhD/S+z9cJLNTZ9tHz1
                7aZQjFyGAyuU3DGW16xfMolcIn+c8TpPCzBOFhxk6jvO
                VLlz+Wgyi1ES+t29FjYYv5cVNRPmxXLRjlHFdO1DzX3N
                dmcUoZ+VVJCvaML9+6UpL/6jitNsoU8JHnxT9B2CGKcw
                N7VaK4l9Ida2BqY3/4UVqWzhj03/M5LK6cn1pEQbQMtY
                R0TNJURBKdK8bH663h98i23tVX0/85IsCVBL4Dd2boa3
                /7HPp7uZN1AjDvcRsOh1mqixwUGmVm1EskDIMy8=
                ) ; KSK; alg = RSASHA256; key id = 45319
example.com.        600 IN NS ns1.example.com.
ftp.example.com.    600 IN RRSIG A 8 3 600 (
                20141126115318 20141027112239 60798 example.com.
                PNATas8HPjc6tm7Ldfk7P61IlRVSQW085P9lDw8qwITc
                TghDdAXHJBkCTXaDRWPyQZbGI5fNcxWLkf/HRbKREzQs
                eyztZj2OBnBnnK0t8SWLyM4+OMsGH17z4ZvBmPO/Wgju
                iSm98reH7J87yRlUMQHdPSwAP6q5tZeJbwpSkao= )
ftp.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126115318 20141027112239 60798 example.com.
                ohuvpkqlNR+TYOG79JizEV+SFjVbUKSB3hEfHOJszCIr
                bcdPKTS0GgQS62N4ISwfvb735oQzc8pI5R+f+8MMn5c9
                /yRnArTpPJOKDnyIiMaMLBU5sEp5wI+OLsLFMkLef4iK
                gn+j608Qnoo7dXtWWQPv85FyaT9j3C+EV6rglCk= )
ftp.example.com.    300 IN NSEC ns1.example.com. A RRSIG NSEC
ftp.example.com.    600 IN A 192.168.1.200
ns1.example.com.    600 IN RRSIG A 8 3 600 (
                20141126115318 20141027112239 60798 example.com.
                z1rnlU9oVnIhwxQey3Zo6ENYmWXtf97RiZng3u6VkE0n
                yUC5S3sseZgD8Vc+uJsKVAvafM/k7NgS+P3pe5gN01Ln
                +geKEMZ3pCHpzHG4UgJj4Xw/iuWOVAFURD26GNnPppDK
                RNYPWIhA/9FF18vI3V9evNcHGxN+7rOOXF8Qbss= )
ns1.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126115318 20141027112239 60798 example.com.
                chH7c6aW6Qk14d4LB866jva9OcH52pJkeHpdslVmUbJ2
                OkJQNhbpOekSjsroxDU4av3/Y49Dtg0lqoISvMMqwE5X
                5sKmn+CMKFfMmi22ui+RsPXyDqjkx+JOsi/7kCx7DFJz
                jF0a6KcsTWNV2QfZjQ50RyrSBBOkw6aqdUC3oF8= )
ns1.example.com.    300 IN NSEC web.example.com. A RRSIG NSEC
ns1.example.com.    600 IN A 192.168.1.1
web.example.com.    600 IN RRSIG CNAME 8 3 600 (
                20141126115318 20141027112239 60798 example.com.
                VgHPC0WllAlHY56xMF3j8FI7MsxDhLJJBDBMSVSQpQkA
                z81kfInYQL4YpAt25WrH7xt4pCmjVl3kUcDGAWWuSiQy
                nh2O4CoY/tSqQ7Sr9UnE5SIvpW5yws8iROOHvJYuKAmu
                8B3gYw1gp9xCMS4iBOIXTTq1KV2OHwo0cPXVyfI= )
web.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126115318 20141027112239 60798 example.com.
                zh+9fnIQlfpvc0oFRnNIPJoL/S5RQF4HuGwmLxoCxRVp
                FCQoZbzNB0IVvaA+0XEslcHq3v4+0j9EeKKQw7xORaGu
                TrzcoRGbjuKZlpvnVlxYkjCiEKVbkXd5yEMnbgolFkhH
                NjFlozSyzypY0TY0UVRPXWhZ2shASae/ImqFiug= )
web.example.com.    300 IN NSEC www.example.com. CNAME RRSIG NSEC
web.example.com.    600 IN CNAME www.example.com.
www.example.com.    600 IN RRSIG A 8 3 600 (
                20141126120153 20141027112239 60798 example.com.
                TLkMRs7I3QW8HRS3trNG307Y0/drO4k8uG8Bv8856qPo
                33rbEajV49XBBQ+w8jynfKwxMNDfJhpSG0gxo7+0m75Y
                HRBZ9Xe3EAMNt2/iu0CL6NHyN99qF9TPNbYnD2Zw077L
                GSDOua1KFMxDqFU7rU0+YlKRGbSk1rqAJBqKEH4= )
www.example.com.    300 IN RRSIG NSEC 8 3 300 (
                20141126120153 20141027112239 60798 example.com.
                GSyFVBgMROqDuoSJoDegX3EkdqA90skBTvi9tkPxoQPo
                i8LlaD+wRmcXpYKE3vf/y0WpOOVQXbasyfFk8wGzFsde
                fqpFsscbz3OYgnkwYcTvGXZF9802ytiC5txli9uxUqjc
                lGL+SDl0woYhecwJD63fTDIMszlVR/eptIL9dLc= )
www.example.com.    300 IN NSEC example.com. A RRSIG NSEC
www.example.com.    600 IN A 192.168.1.100

But this is a really messy way to tell if your zone is properly setup with DNSSEC. Fortunately, there are tools to help us with that. Read on to Section 4.2, “How To Test Authoritative Zones (So You Think You Are Signed)” to learn more.

4.2. How To Test Authoritative Zones (So You Think You Are Signed)

So we’ve generated some keys, ran some commands, and uploaded some data to our parent zone. How do we know our zone is signed correctly? Here are a few ways to check.

4.2.1. Look for Key Data in Your Zone

One of the ways to see if your zone is signed, is to check for the presence of DNSKEY record types. In our example, we created two keys, and we expect to see both keys returned when we query for them.

$ dig @192.168.1.13 example.com. DNSKEY +multiline +noall +answer

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. DNSKEY +multiline +noall +answer
; (1 server found)
;; global options: +cmd
example.com.        300 IN DNSKEY 256 3 8 (
                AwEAAclob7q+ccvDwaTVuMM2ddGIynWyMwaZlhFrU6cC
                0qknWoPpkq0gIwTrYf3DJY+eIKPVHxrM+o2AoRIVhubG
                jfv1bT5wTYrawZstS84ejCQ+ehA+8DxKyeWUEzW0ZMBe
                OhyeG0cuQVK/p6Z1E096JLu0DjgbabLspequkw4M+HT7
                ) ; ZSK; alg = RSASHA256; key id = 57009
example.com.        300 IN DNSKEY 257 3 8 (
                AwEAAdQ2ctHx8VmryndiOgpchXPdj3NwxMeUvAre6uYI
                5KELlFJUghTHrz+/CzEc8CXG8wwQ4ZvAey0FGV2nJAFC
                ENMxoRiCz0oSiQQxryNhACd3RnE2/D7G+ShwlOM6w53E
                wUJ/lsgu5UevSxFC+eA3fKeL3TWR44PH4iJQp9QmfW5v
                7qG8Sic/HQvBGBdOGfFtHAl0a4jDPBi57imS4YsHcUYD
                9bsWmhYWSHJKZ66+JnTiMS0nQM69YwBF43QfDKurs5R6
                qPUDiBlaMCzSxmlaBU6fsI1Mu/yIU8w1ewy26a42rUTU
                rPBC3Oa/zf9VQ8kpUrMZgJ7LEAA4xmR+qwWDh6U=
                ) ; KSK; alg = RSASHA256; key id = 28267

4.2.2. Look for Signatures in Your Zone

Another way to see if your zone data is signed is to check for the presence of signature. With DNSSEC, every record[3]now comes with at least one corresponding signature known as RRSIG.

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. SOA +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31466
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;example.com.       IN SOA

;; ANSWER SECTION:
example.com.        300 IN SOA ns1.example.com. dnsadmin.example.com. (
                2014102111 ; serial
                10800      ; refresh (3 hours)
                1080       ; retry (18 minutes)
                2419200    ; expire (4 weeks)
                900        ; minimum (15 minutes)
                )
example.com.        300 IN RRSIG SOA 8 2 300 (
                20141121122105 20141022112105 57009 example.com.
                NqPGNLkUs40Lg/qq7Fv+bgyCwVB4s9PsHQOK6p9ZWWk3
                36z2Qz2WjM+Q19SlVBAPux9jijvcRcjGb6KREuxER9uX
                wdVeiGx9a4X+PaO3qTqdkiXuGS2XkK1kBm1CgwhVHTYV
                /nxVPrckU4/mpeUoFVjMnT49JkVJmgck63esPEU= )

The serial number was automatically incremented from the old, unsigned version. Named keeps track of the serial number of the signed version of the zone independently of the unsigned version. If the unsigned zone is updated with a new serial number that’s higher than the one in the signed copy, then the signed copy will be increased to match it, but otherwise the two are kept separate.

4.2.3. Examine the Zone File

Our original zone file example.com.db remains untouched, named has generated 3 additional files automatically for us (shown below). The signed DNS data is stored in example.com.db.signed and in the associated journal file.

# cd /etc/bind/db
# ls
example.com.db  example.com.db.jbk  example.com.db.signed  example.com.db.signed.jnl

A quick description of each of the files:

  • .jbk: transient file used by named
  • .signed: signed version of the zone in raw format
  • .signed.jnl: journal file for the signed version of the zone

These files are stored in raw (binary) format for faster loading. You could reveal the human-readable version by using named-compilezone as shown below. In the example below, we are running the command on the raw format zone example.com.db.signed to produce a text version of the zone example.com.text:

# named-compilezone -f raw -F text -o example.com.text example.com example.com.db.signed
zone example.com/IN: loaded serial 2014112008 (DNSSEC signed)
dump zone to example.com.text...done
OK

4.2.4. Check the Parent

Although this is not strictly related to whether or not the zone is signed, but a critical part of DNSSEC is the trust relationship between the parent and child. Just because we, the child, have all the correctly signed records in our zone doesn’t mean it can be fully validated by a validating resolver, unless our parent’s data agrees with us. To check if our upload to the parent is successful, ask the parent name server for the DS record of our zone, and we should get back the DS record(s) containing the information we uploaded in Section 4.1.4, “Upload to Parent Zone”:

$ dig example.com. DS

; <<>> DiG 9.10.1 <<>> example.com. DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49949
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.           IN  DS

;; ANSWER SECTION:
example.com.  61179 IN  DS  28267 8 1 66D47CE4B4F551BE5EDA43AC5F3109E8C98E2FAE
example.com.  61179 IN  DS  28267 8 2 71D9335416B7132519190A95685E18CBF478DCF4CA98867062777938F8FEAB89

4.2.5. External Testing Tools

The easiest ways to see if your domain name is fully secured is to use one of these excellent online tools.

4.2.5.1. Verisign DNSSEC Debugger

URL: http://dnssec-debugger.verisignlabs.com/

This tool shows a nice summary of checks performed on your domain name, and you can expand to view more details for each of the items checked to get a detailed report.

Figure 4.1. Verisign DNSSEC Debugger

Verisign DNSSEC Debugger

4.2.5.2. DNSViz

URL: http://dnsviz.net/

DNSViz provides a visual analysis of the DNSSEC authentication chain for a domain name and its resolution path in the DNS namespace.

Figure 4.2. DNSViz

DNSViz

4.2.5.3. Sec Spider

URL: http://secspider.cs.ucla.edu/

Similar to DNSViz, with the added bonus of letting users move elements on the diagram.

Figure 4.3. Sec Spider

Sec Spider

4.3. Signing Easy Start Explained

4.3.1. Generate Keys Explained

In Section 4.1.1, “Generate Keys”, we generated two pairs of keys: a pair of Zone Signing Keys (ZSK) and a pair of Key Signing Keys (KSK). To quickly summarize, ZSKs sign the bulk of the zone, but KSKs only sign the DNSKEYs. This makes ZSKs easier to change (since you can do so without updating the parent). We generated keys by running these commands:

# cd /etc/bind/keys/example.com
# dnssec-keygen -a RSASHA256 -b 1024 example.com
Generating key pair...++++++ .............++++++ 
Kexample.com.+008+17694
# dnssec-keygen -a RSASHA256 -b 2048 -f KSK example.com
Generating key pair........................+++ ..................................+++ 
Kexample.com.+008+06817

With these commands, we generated NSEC3-compatible key pairs (see Section 6.2.2, “NSEC3” to learn more about NSEC3). In the end, four key files were created in /etc/bind/keys/example.com:

  • Kexample.com.+008+06817.key
  • Kexample.com.+008+06817.private
  • Kexample.com.+008+17694.key
  • Kexample.com.+008+17694.private

The two files ending in .private need to be kept, well, private. These are your private keys, guard them carefully. You should at the very least protect them via file permission settings. Please see Section 6.3, “Key Storage” for more information about how to store your keys.

The two files ending in .key are your public keys. One is the zone-signing key (ZSK), and one is the key-signing Key (KSK). We can tell which is which by looking at the actual file contents (actual keys shortened for display):

# cat Kexample.com.+008+06817.key
; This is a key-signing key, keyid 6817, for example.com.
; Created: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R
# cat Kexample.com.+008+17694.key
; This is a zone-signing key, keyid 17694, for example.com.
; Created: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Publish: 20141120094536 (Thu Nov 20 17:45:36 2014)
; Activate: 20141120094536 (Thu Nov 20 17:45:36 2014)
example.com. IN DNSKEY 256 3 8 AwEAAcjGaU...zuu55If5

The first line of each file tell us what type of key it is. Also, by looking at the actual DNSKEY record, we could tell them apart: 256 is ZSK, and 257 is KSK.

So, this is a ZSK:

# cat Kexample.com.+008+17694.key
...
example.com. IN DNSKEY 256 3 8 AwEAAcjGaU...zuu55If5

And this is a KSK:

# cat Kexample.com.+008+06817.key
...
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

The parameters we showed in the example, algorithm of RSASHA256, key length of 1024 and 2048, and the use of NSEC3 are just suggestions, you need to evaluate what values work best for your environment. To learn more about key generation, different algorithm choices, and key sizes, see Section 6.1, “Key Generation”.

The table below summarizes the usage and frequency of use for each of the keys.

Table 4.1. ZSK KSK Comparison

Key Usage Frequency of Use
ZSK Private Used by authoritative server to create RRSIG for zone data Used somewhat frequently depending on the zone, whenever authoritative zone data changes or re-signing is needed
ZSK Public Used by recursive server to validate zone data RRset Used very frequently, whenever recursive server validates a response
KSK Private Used by authoritative server to create RRSIG for ZSK and KSK Public (DNSKEY) Very infrequently, whenever ZSK’s or KSK’s change (every year or every five years in our examples)
KSK Public Used by recursive server to validate DNSKEY RRset Used very frequently, whenever recursive server validates a DNSKEY RRset

4.3.2. Reconfigure BIND Explained

In Section 4.1.2, “Reconfigure BIND”, we highlighted a few lines, let’s explain what each one of them does.

options {
    directory "/etc/bind";
    recursion no;
    minimal-responses yes;
};

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
};

4.3.2.1. dnssec-enable

DNSSEC support is enabled in named by default. If the dnssec-enable option is turned off, named will be unable to serve signed zones.

4.3.2.2. key-directory

zone "example.com" IN {
    key-directory "keys/example.com";
};

This specifies where named should look for public and private DNSSEC key files. The default is named‘s working directory. In our example, we organized keys based on zone names, and placed all keys for example.comunder one directory /etc/bind/keys/example.com.

4.3.2.3. inline-signing

zone "example.com" IN {
    inline-signing yes;
};

This option is disabled by default. When enabled, BIND converts traditional (insecure) zone data to signed (secure) data automatically and transparently, using keys found in key-directory.

This feature alleviates the burden of re-signing zone data put on DNSSEC zone administrators. As the zone administrator, you can continue to manually maintain the unsigned version of the zone just like before, and namedautomatically creates an internal copy of the zone, signs it on the fly, and increments the serial number for the signed zone. The unsigned version of the zone is left intact. With this feature enabled, whenever named detects that your zone needs to be signed, either due to a new record being added, removed, or signature expiration, it will automatically re-sign the zone data.

Inline signing can also be used as a strategy to aid DNSSEC deployment in the case where the master zone cannot be easily modified To learn more about inline signing, please see Section 6.5.2, “DNSSEC and Inline Signing”.

4.3.2.4. auto-dnssec

zone "example.com" IN {
    auto-dnssec maintain;
};

With keys, comes the burden of key management. auto-dnssec provides varying levels of automatic key management. There are three possible settings:

  1. off: this is the default, key management is done manually
  2. allow: permits keys to be updated and the zone fully re-signed whenever the user issues the command rndc sign [zonename].
  3. maintain: includes what “allow” has, but also automatically adjusts the zone’s DNSSEC keys on schedule, according to the key’s timing metadata.

We have opted for the “maintain” mode in our example, which provides the most automated key management. With this option enabled, BIND will periodically check to see if new keys are available, or old keys need to be retired, and automatically add or remove the appropriate DNSKEY records from the zone. The frequency of the check can be controlled via dnssec-loadkeys-interval, default is 60 minutes (1 hour).

Note

auto-dnssec is a feature to automate many of the key management tasks, which we discuss in more detail in Section 6.4.2.1, “Manual Key Management and Signing”, to cover topics such as manual signing and key timing metadata.

4.4. Working with Parent Zone

As we mentioned in Section 4.1.4, “Upload to Parent Zone”, the format of the information you upload to your parent zone is dictated by your parent zone administrator, and the three main formats are:

  1. DS Record Format
  2. DNSKEY Format
  3. Trusted Key Format

ICANN maintains a list of registrars who support DNSSEC:

https://www.icann.org/resources/pages/deployment-2012-02-25-en

Next, we will take a look at how to get each of the three formats from your existing data.

4.4.1. DS Record Format

Below is an example of generating DS record formats from the KSK we created earlier (Kexample.com.+008+28267.key) using two different secure hashing algorithms (SHA-1 and SHA-256, respectively):

# cd /etc/bind/keys/example.com
# dnssec-dsfromkey -a SHA-1 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
# dnssec-dsfromkey -a SHA-256 Kexample.com.+008+06817.key
example.com. IN DS 6817 8 2 2A5F1DF55D5E64CBD7BCFE1EFA6E9586AF335FA56A2473296E975B89AFD31E11

Some registrars many ask you to manually specify the types of algorithm and digest used. In the first example, 8 represents the algorithm used, and 1 represents the digest type (SHA-1); in the second example, 8 is the algorithm, and 2 is the digest type (SHA-256). The key tag or key ID is 28267.

Alternatively, you could generate it from the DNSKEY records like this:

$ dig @192.168.1.13 example.com. DNSKEY | dnssec-dsfromkey -f - example.com
example.com. IN DS 6817 8 1 59194A835ACD78D25D538D5F35CA043A8F3F4446
example.com. IN DS 6817 8 2 2A5F1DF55D5E64CBD7BCFE1EFA6E9586AF335FA56A2473296E975B89AFD31E11

4.4.2. DNSKEY Format

Below is an example of a different key ID (16027) using DNSKEY format (actual key shortened for display):

example.com. 172800 IN DNSKEY 257 3 8 (AwEAAbGOPf...AX2QHMY8=) ; key id = 16027

The key itself is easy to find (it’s kind of hard to miss that big long base64 string) in the file. Remember, we want KSK, so look for the presence of 257.

# cd /etc/bind/keys/example.com
# cat Kexample.com.+008+06817.key
; This is a key-signing key, keyid 6817, for example.com.
; Created: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)
example.com. IN DNSKEY 257 3 8 AwEAAcWDps...lM3NRn/G/R

Some registrars may ask you to manually specify the type of algorithm used and the key tag number. In our example above, the chosen algorithm is 8, and the key ID is 6817.

4.4.3. Trusted Key Format

This format is very similar to the DNSKEY format, the differences are mostly cosmetic. Below is an example of trusted-keys format (again, actual key shortened for display):

"example.com." 257 3 8 "AwEAAbGOPf...9AX2QHMY8=";

4.4.4. What if My Parent Zone Doesn’t Support DNSSEC?

Without a parent zone to vouch for you, none of your new shiny DNSSEC records will yield to much significance when it comes to validation. Your zone will still be resolvable without cooperation from your parent zone.

But not all hope is lost. Assuming you want everyone on the Internet to be able to validate your DNS data, you should do both of the followings:

  1. Contact your registrar and ask for DNSSEC support.
  2. Look into using Section 6.5.3, “DNSSEC Look-aside Validation (DLV)”.

The long term solution is still to have your parent zone work with you. If your registrar does not support DNSSEC, maybe it’s time to switch to one that does.

4.5. Using NSEC3

After reloading the server configuration file, additional DNSSEC resource records are auto-magically generated. By default, BIND will generate NSEC records. If you wish to use NSEC3 instead, please follow the steps described in Section 7.3.1, “Migrating from NSEC to NSEC3”. To learn more about the difference between NSEC and NSEC3, please see Section 6.2, “Proof of Non-Existence (NSEC and NSEC3) ”.

4.6. Maintenance Tasks

Zone data is signed, parent zone has published your DS records, at this point your zone is officially secure. When other validating resolvers lookup information in your zone, they are able to follow the 12-step process as described in Section 3.3.2, “How Does DNSSEC Change DNS Lookup (Revisited)?” and verify the authenticity and integrity of the answers.

There is not that much left for you to do, as the DNS administrator, at an ongoing basis. Whenever you update your zone, BIND will automatically resign your zone with new RRSIG and NSEC or NSEC3 records, and even increment the serial number for you.

That leaves DNSKEY records. Just like passwords and underwear, keys should be changed periodically. There are arguments for and against rolling keys, which are discussed elsewhere. If you decide to change your keys, we recommend changing your ZSK pair anually, and your KSK pair every five years. This is also known as a key rollover.

Why annually for the ZSK? That’s just a convenient length of time that probably coincides with your domain name registration/renewal cycle; And every five years? That’s also a generic length of time, one which happens to be the same as the root key’s rollover schedule. Some people feel or have the need to do it more frequently, while some argue that there is no need for key rolling. We discuss those considerations in Section 6.4.1, “Key Rollovers”. But assuming you do not have special security requirements, nor do you host a high valued zone, rotating your ZSK every year and KSK every five years should suffice. We also provide detailed step-by-step examples of each rollover in Section 7.2, “Rollover Recipes”.

4.6.1. ZSK Rollover

Assuming you are rolling over ZSK every year on January 1st, below is the timeline of what should happen:

  1. December 1st, a month before rollover date

    • Change timer on current ZSK
    • Generate new ZSK
    • Publish new DNSKEY
  2. January 1st, day of rollover

    • New ZSK used to replace RRSIGs for the bulk of the zone
  3. February 1st, a month after rollover date

    • Remove old DNSKEY from zone
    • DNSKEY signatures made with KSK are changed

This may look like a lot of work, but with inline-signing and auto-dnssec, most of these are automated. The only thing that needs to be done manually are just the first two items:

  • Change timer on current ZSK
  • Generate new ZSK

For an example of how to execute a ZSK rollover, please see Section 7.2.1, “ZSK Rollover Recipe”.

4.6.2. KSK Rollover

KSK rollover is very similar to ZSK, with the addition of interacting with the parent zone. In fact, as you can see below, the timeline looks nearly identical to the ZSK rollover, with the addition of interaction with parent zone:

  1. December 1st, a month before rollover date

    • Change timer on current KSK
    • Generate new KSK and DS records
    • Upload new DS records to parent zone
  2. January 1st, day of rollover

    • Use new KSK to sign all DNSKEY RRset, this generates new RRSIGs
    • Add new RRSIGs to the zone
    • Remove old RRSIGs from zone
  3. February 1st, a month after rollover date

    • Remove old KSK DNSKEY from zone
    • Remove old DS records from parent zone

Unfortunately, as of this writing, KSK rollover involves a lot of manual steps. As described above, the only automated tasks are the ones that occur on the day of the rollover (January 1st), everything else needs to be done manually. To see an example of how to perform a KSK rollover, please see Section 7.2.2, “KSK Rollover Recipe”.


[3] Well, almost every record. NS records and glue records for delegations do not have RRSIG records like everyone else. If you do not have any delegations, then yes, every record in your zone will be signed and comes with its own RRSIG.

Chapter 5. Basic Troubleshooting

In this chapter, we are going to cover some basic troubleshooting techniques, common DNSSEC symptoms, and their solutions and causes. This is not a comprehensive “how to troubleshoot any DNS or DNSSEC problem” guide, because that in and of itself could easily be an entire book.

5.1. Query Path

The first step to your DNS or DNSSEC troubleshooting should be to determine the query path. This is not a DNSSEC-specific troubleshooting technique. Whenever you are working with a DNS-related issue, it is always a good idea to determine the exact query path to identify the origin of the problem.

End clients, such as laptop computers or mobile phones, are configured to talk to a recursive name server, and the recursive name server may in turn forward on to more recursive name servers, before arriving at the authoritative name server. The giveaway is the presence of the Authoritative Answer (aa) flag: when present, we know we are talking to the authoritative server; when missing, we are talking to the recursive server. The example below shows an answer without the Authoritative Answer flag:

$ dig www.example.com. A

; <<>> DiG 9.10.1 <<>> www.example.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41006
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; ANSWER SECTION:
www.example.com.    600 IN  A   192.168.1.100

;; Query time: 21 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Mon Nov 03 19:54:37 CST 2014
;; MSG SIZE  rcvd: 60

Not only do we not see the aa flag, we see the presence of an ra flag, which represents Recursion Available. This indicates that the server we are talking to (192.168.1.7 in this example) is a recursive name server. And although we were able to get an answer for http://www.example.com, the answer came from somewhere else.

The example below shows when we query the authoritative server directly and see the presence of the aa flag:

$ dig @192.168.1.13 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.13 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
...

The presence of the aa flag tells us that we are now talking to the authoritative name server for example.com, and this is not a cached answer it obtained from some other name server, it served this answer to us right from its own database. In fact, if you look closely, the ra flag is not present, which means this name server is not configured to perform recursion (at least not for this client), so it could not have queried another name server to get cached results anyway.

5.2. Visible Symptoms

After you have figured out the query path, the next thing to do is to determine whether or not the problem is actually related to DNSSEC validation. You can use the +cd flag in dig to disable validation, as described inSection 3.2.5, “How Do I know I Have a Validation Problem?”.

When there is indeed a DNSSEC validation problem, the visible symptoms, unfortunately, are very limited. With DNSSEC validation enabled, if a DNS response is not fully validated, it will result in a generic SERVFAIL message, as shown below when querying against a recursive name server 192.168.1.7:

$ dig @192.168.1.7 www.isc.org. A
; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.isc.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8101
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.isc.org.           IN  A

;; Query time: 973 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Thu Oct 16 20:28:20 CST 2014
;; MSG SIZE  rcvd: 40

With delv, a “resolution failed” message is output instead:

$ delv @192.168.1.7 www.isc.org. A +rtrace
;; fetch: www.isc.org/A
;; resolution failed: failure

5.3. Logging

DNSSEC validation error messages by default will show up in syslog as a Query-Error. It will have the string “error” at the start of the message. Here is an example of what it may look like:

error (insecurity proof failed) resolving './NS/IN': 192.168.1.13#53

Usually, this level of error logging should suffice for most. If you would like to get more detailed information about why DNSSEC validation failed, read on to Section 5.3.1, “BIND DNSSEC Debug Logging” to learn more.

5.3.1. BIND DNSSEC Debug Logging

A word of caution: before you enable debug logging, be aware that this may dramatically increase the load on your name servers.

With that said, sometimes it may become necessary to temporarily enable BIND debug logging to see more details of how DNSSEC is validating (or not). DNSSEC-related messages are not recorded in syslog by default, even if query log is enabled, only DNSSEC errors will show up in syslog. Enabling debug logging is not recommended for production servers, as it increases load on the server.

The example below shows how to enable debug level 3 (to see full DNSSEC validation messages) in BIND9 and have it sent to syslog:

logging {
   channel dnssec_log {
        syslog daemon;
        severity debug 3;
        print-category yes;
    };
    category dnssec { dnssec_log; };
};

The example below shows how to log DNSSEC messages to their own file:

logging {
   channel dnssec_log {
        file "/var/log/dnssec.log";
        severity debug 3;
    };
    category dnssec { dnssec_log; };
};

After restarting BIND, a large number of log messages will appear in syslog. The example below shows the log messages as a result of successfully looking up and validating the domain name http://www.isc.org.

validating @0xb8012d88: . NS: starting
validating @0xb8012d88: . NS: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: starting
validating @0xb805a9b0: . DNSKEY: attempting positive response validation
validating @0xb805a9b0: . DNSKEY: verify rdataset (keyid=19036): success
validating @0xb805a9b0: . DNSKEY: signed by trusted key; marking as secure
validator @0xb805a9b0: dns_validator_destroy
validating @0xb8012d88: . NS: in fetch_callback_validator
validating @0xb8012d88: . NS: keyset with trust 8
validating @0xb8012d88: . NS: resuming validate
validating @0xb8012d88: . NS: verify rdataset (keyid=8230): success
validating @0xb8012d88: . NS: marking as secure, noqname proof not needed
validator @0xb8012d88: dns_validator_destroy
validating @0xb8012d88: www.isc.org A: starting
validating @0xb8012d88: www.isc.org A: attempting positive response validation
validating @0xb805a9b0: isc.org DNSKEY: starting
validating @0xb805a9b0: isc.org DNSKEY: attempting positive response validation
validating @0xb827e298: isc.org DS: starting
validating @0xb827e298: isc.org DS: attempting positive response validation 
validating @0xb827fd18: org DNSKEY: starting
validating @0xb827fd18: org DNSKEY: attempting positive response validation 
validating @0xb8281798: . NS: starting
validating @0xb8281798: . NS: attempting positive response validation 
validating @0xb8281798: . NS: keyset with trust 8
validating @0xb8280790: org DS: starting
validating @0xb8280790: org DS: attempting positive response validation 
validating @0xb8280790: org DS: keyset with trust 8
validating @0xb8280790: org DS: verify rdataset (keyid=8230): success
validating @0xb8280790: org DS: marking as secure, noqname proof not needed
validator @0xb8280790: dns_validator_destroy
validating @0xb827fd18: org DNSKEY: in dsfetched
validating @0xb827fd18: org DNSKEY: dsset with trust 8
validating @0xb827fd18: org DNSKEY: verify rdataset (keyid=21366): success
validating @0xb827fd18: org DNSKEY: marking as secure (DS)
validator @0xb827fd18: dns_validator_destroy
validating @0xb827e298: isc.org DS: in fetch_callback_validator
validating @0xb827e298: isc.org DS: keyset with trust 8
validating @0xb827e298: isc.org DS: resuming validate
validating @0xb827e298: isc.org DS: verify rdataset (keyid=33287): success
validating @0xb827e298: isc.org DS: marking as secure, noqname proof not needed
validator @0xb827e298: dns_validator_destroy
validating @0xb805a9b0: isc.org DNSKEY: in dsfetched 
validating @0xb805a9b0: isc.org DNSKEY: dsset with trust 8
validating @0xb805a9b0: isc.org DNSKEY: verify rdataset (keyid=12892): success
validating @0xb805a9b0: isc.org DNSKEY: marking as secure (DS)
validator @0xb805a9b0: dns_validator_destroy
validating @0xb8012d88: www.isc.org A: in fetch_callback_validator

5.4. Common Problems

5.4.1. Security Lameness

Similar to Lame Delegation in traditional DNS, this refers to the symptom when the parent zone holds a set of DS records that point to something that does not exist in the child zone. The resulting symptom is that the entire child zone may “disappear”, being marked as bogus by validating resolvers.

Below is an example attempting to resolve the A record for a test domain name http://www.example.com. From the user’s perspective, as described in Section 3.2.5, “How Do I know I Have a Validation Problem?”, only SERVFAIL message is returned. On the validating resolver, we could see the following messages in syslog:

named[6703]: error (no valid RRSIG) resolving 'example.com/DNSKEY/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/DS/IN': 149.20.61.151#53
named[6703]: error (broken trust chain) resolving 'www.example.com/A/IN': 149.20.61.151#53

This gives us a hint that it is a broken trust chain issue. Let’s take a look at the DS records that are published by querying one of the public DNS resolvers that supports DNSSEC. We have highlighted in the key tag ID returned, and shortened some keys for display:

$ dig @8.8.8.8 example.com. DS

; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9640
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com.       IN  DS

;; ANSWER SECTION:
example.com.    21599   IN  DS  53476 8 2 1544D......7DDA7
example.com.    21599   IN  DS  53476 8 1 CD2AF...0B47B

;; Query time: 212 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 27 17:23:42 CST 2014
;; MSG SIZE  rcvd: 133

Next, we query for the DNSKEY and RRSIG of example.com, to see if there’s anything wrong. Since we are having trouble validating, we flipped on the +cd option to disable checking for now to get the results back, even though they do not pass the validation tests. The +multiline option tells dig to print the type, algorithm type, and key id for DNSKEY records. Again, key tag ID’s are highlighted, and some long strings are shortened for display:

$ dig @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline

; <<>> DiG 9.10.1 <<>> @8.8.8.8 example.com. DNSKEY +dnssec +cd +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20329
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;example.com.   IN DNSKEY

;; ANSWER SECTION:
example.com.    299 IN DNSKEY 257 3 8 (
                AwEAAePggU...0VPPEX+DE=
                ) ; KSK; alg = RSASHA256; key id = 48580
example.com.    299 IN DNSKEY 256 3 8 (
                AwEAAbMZp6...NRJnwyC/uX
                ) ; ZSK; alg = RSASHA256; key id = 60426
example.com.    299 IN RRSIG DNSKEY 8 2 300 (
                20141227074820 20141127064820 48580 example.com.
                ph3eBXsBQy...fQTRTlpg== )
example.com.    299 IN RRSIG DNSKEY 8 2 300 (
                20141227074820 20141127064820 60426 example.com.
                VaQ0INIa3a...nj3YTPv5A= )

;; Query time: 368 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 28 11:33:00 CST 2014
;; MSG SIZE  rcvd: 961

Here is our problem: the parent zone is telling the world that example.com is using the key 53476, but the authoritative servers are saying: no no no, I am using keys 48580 and 60426. There might be several causes for this mismatch, one possibility is that a malicious attacker has compromised one side and change the data. The more likely scenario is that the DNS administrator for the child zone did not upload the correct key information to the parent zone.

5.4.2. Incorrect Time

In DNSSEC, every record will come with at least one RRSIG, and RRSIG contains two timestamps indicating when it starts becoming valid, and when it expires. If the validating resolver’s current system time does not fall within the RRSIG two timestamps, the following error messages occur in BIND debug log.

First, the example below shows the log messages when the RRSIG has expired. This could mean the validating resolver system time is incorrectly set too far in the future, or the zone administrator has not kept up with RRSIG maintenance.

validating @0xb7b839b0: . DNSKEY: verify failed due to bad signature (keyid=19036): RRSIG has expired

The logs below show RRSIG validity period has not begun. This could mean validation resolver system is incorrectly set too far in the past, or the zone administrator has incorrectly generated signatures for this domain name.

validating @0xb7c1bd88: www.isc.org A: verify failed due to bad signature (keyid=4521): RRSIG validity period has not begun

5.4.3. Invalid Trust Anchors

As we have seen in the section Section 3.4, “Trust Anchors”, whenever a DNSKEY is received by the validating resolver, it is actually compared to the list of keys the resolver has explicitly trusted to see if further action is needed. If the two keys match, the validating resolver stops performing further verification and returns the answer(s) as validated.

But what if the key file on the validating resolver is misconfigured or missing? Below we show some examples of log messages when things are not working properly.

First of all, if the key you copied is malformed, BIND will not even start up and you will likely find this error message in syslog:

named[18235]: /etc/bind/named.conf.options:29: bad base64 encoding
named[18235]: loading configuration: failure

If the key is a valid base64 string, but the key algorithm is incorrect, or if the wrong key is installed, the first thing you will notice is that pretty much all of your DNS lookups result in SERVFAIL, even when you are looking up domain names that have not been DNSSEC-enabled. Below shows an example of querying a recursive server 192.168.1.7:

$ dig @192.168.1.7 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.7 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8093
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.           IN  A

delv shows similar result:

$ delv @192.168.1.7 www.example.com. +rtrace
;; fetch: www.example.com/A
;; resolution failed: failure

The next symptom you will see is in the DNSSEC log messages:

validating @0xb8b18a38: . DNSKEY: starting
validating @0xb8b18a38: . DNSKEY: attempting positive response validation
validating @0xb8b18a38: . DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for '.'
validating @0xb8b18a38: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf.

5.4.4. Unable to Load Keys

This is a simple yet common issue. If the keys files were present but not readable by named, the syslog messages are clear, as shown below:

named[32447]: zone example.com/IN (signed): reconfiguring zone keys
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+06817.private: permission denied
named[32447]: dns_dnssec_findmatchingkeys: error reading key file Kexample.com.+008+17694.private: permission denied
named[32447]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:04:36.521

However, if no keys are found, the error is not as obvious. Below shows the syslog messages after executing rndc reload, with the key files missing from the key directory:

named[32516]: received control channel command 'reload'
named[32516]: loading configuration from '/etc/bind/named.conf'
named[32516]: reading built-in trusted keys from file '/etc/bind/bind.keys'
named[32516]: using default UDP/IPv4 port range: [1024, 65535]
named[32516]: using default UDP/IPv6 port range: [1024, 65535]
named[32516]: sizing zone task pool based on 6 zones
named[32516]: the working directory is not writable
named[32516]: reloading configuration succeeded
named[32516]: reloading zones succeeded
named[32516]: all zones loaded
named[32516]: running
named[32516]: zone example.com/IN (signed): reconfiguring zone keys
named[32516]: zone example.com/IN (signed): next key event: 27-Nov-2014 20:07:09.292

This happens to look exactly the same as if the keys were present and readable, and named loaded the keys and signed the zone. It will even generate the internal (raw) files:

# cd /etc/bind/db
# ls
example.com.db  example.com.db.jbk  example.com.db.signed

If named really loaded the keys and signed the zone, you should see the following files:

# cd /etc/bind/db
# ls
example.com.db  example.com.db.jbk  example.com.db.signed  example.com.db.signed.jnl

So, unless you see the *.signed.jnl file, your zone has not been signed.

5.5. NSEC3 Troubleshooting

BIND includes a tool called nsec3hash that runs through the same steps a validating resolver would, to generate the correct hashed name based on NSEC3PARAM parameters. The command takes the following parameters in order: salt, algorithm, iterations, and domain. For example, if the salt is 1234567890ABCDEF, hash algorithm is 1, and iteration is 10, to get the NSEC3-hashed name for http://www.example.com we would execute a command like this:

$ nsec3hash 1234567890ABCEDF 1 10 www.example.com
RN7I9ME6E1I6BDKIP91B9TCE4FHJ7LKF (salt=1234567890ABCEDF, hash=1, iterations=10)

While it is unlikely you would construct a rainbow table of your own zone data, this tool might be useful to troubleshoot NSEC3 problems.

5.6. Troubleshooting Example

Let’s put what we’ve looked at together into an example and see the steps taken to solve the problem. We start with someone complaining that she is unable to resolve the name http://www.example.com. We use dig on her machine to verify the behavior, and we received the following output from dig:

$ dig www.example.com. A

; <<>> DiG 9.10.1 <<>> www.example.com. A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26068
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; Query time: 784 msec
;; SERVER: 192.168.1.7#53(192.168.1.7)
;; WHEN: Mon Nov 03 20:00:45 CST 2014
;; MSG SIZE  rcvd: 44

We learned from this output that the recursive name server 192.168.1.7 returned a generic error message when resolving the name http://www.example.com. The next step is to look at the DNS server configuration on 192.168.1.7 to see how it is configured. Below is an excerpt of named.conf from 192.168.1.7:

options {
    ...
    forwarders {192.168.1.11;};
    forward only;
    ...
};

This tells us that the recursive name server 192.168.1.7 just sends all recursive queries to 192.168.1.11. Let’s query 192.168.1.11:

$ dig @192.168.1.11 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.11 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24171
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
...

And we get the same result as when we queries 192.168.1.7, generic failure message, but we also learned that 192.168.1.11 is not authoritative for example.com (no aa flag), so it is getting this response from somewhere else. Below is the configuration excerpt from 192.168.1.11:

options {
    ...
    forwarders {};
    forward only;
    ...
};

zone "example.com" IN {
    type forward;
    forwarders { 192.168.1.13; };
    forward only;
};

At first glance, it may look like 192.168.1.11 is just performing recursion itself, querying Internet name servers directly; however, further down the configuration file, we see the forward zone definition, which tell us that 192.168.1.11 is doing conditional forwarding just for example.com, and it is sending all example.com queries to 192.168.1.13.

We then query 192.168.1.13:

$ dig @192.168.1.13 www.example.com. A

; <<>> DiG 9.10.1 <<>> @192.168.1.13 www.example.com. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35962
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; ANSWER SECTION:
www.example.com.    600 IN  A   192.168.1.100

;; Query time: 4 msec
;; SERVER: 192.168.1.13#53(192.168.1.13)
;; WHEN: Mon Nov 03 20:06:26 CST 2014
;; MSG SIZE  rcvd: 60

Finally! We found the authoritative name server! Now we know our query path looks like this:

Figure 5.1. Query Path

Query Path

But 192.168.1.13 has no trouble answering the query for http://www.example.com, so the problem might be between 192.168.1.11 and 192.168.1.13? We know there are no firewalls or network devices between 192.168.1.11 and 192.168.1.13 that could intercept packets. Let’s query 192.168.1.11 again, but this time, let’s purposely turn off DNSSEC validation by using +cd (checking disabled), to see if this error message was caused by DNSSEC validation:

$ dig @192.168.1.11 www.example.com. A +cd

; <<>> DiG 9.10.1 <<>> @192.168.1.11 www.example.com. A +cd
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58332
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; ANSWER SECTION:
www.example.com.    562 IN  A   192.168.1.100

;; Query time: 2 msec
;; SERVER: 192.168.1.11#53(192.168.1.11)
;; WHEN: Mon Nov 03 20:01:23 CST 2014
;; MSG SIZE  rcvd: 60

Bingo! So the problem is on 192.168.1.11, and specifically, with DNSSEC validation. Now we can focus our attention on the configuration on 192.168.1.11, examine its logs, check its system time, or check its trust anchors, to see what may be the root cause.

Examining log messages from 192.168.1.11, we notice the following two entries:

error (no valid KEY) resolving 'example.com/DNSKEY/IN': 192.168.1.13#53
error (broken trust chain) resolving 'www.example.com/A/IN': 192.168.1.13#53

So it would appear that on the server 192.168.1.11, there is a broken trust chain. At this point, we can probably conclude the problem is in one of the trusted-keys statements on 192.168.1.11, but let’s turn on DNSSEC debug logging (as described in Section 5.3.1, “BIND DNSSEC Debug Logging”), and re-run the dig for http://www.example.com one more time to see what log messages get generated:

...
validating @0xb4b48968: example.com DNSKEY: attempting positive response validation
validating @0xb4b48968: example.com DNSKEY: unable to find a DNSKEY which verifies the DNSKEY RRset and also matches a trusted key for 'example.com'
validating @0xb4b48968: example.com DNSKEY: please check the 'trusted-keys' for 'example.com' in named.conf.
...

Okay, so we have a confirmed log message telling us to look at ‘trusted-keys‘. The named.conf on 192.168.1.11 contains the following:

trusted-keys {
    example.com. 257 3 8 "AwEAAbluLK0k3dPKnsJNd5tGbO5bgh7WuXzaSDQVwi/qqPdCR65ZDiin
                          0GTpL++B1iKYDP4rRL/s/2TMppI1fV638f2SuhNQ9zYIuCo/FuHeJB7/
                          DBQ03eJFvN1QHC0we2uUFrXazz8eT9nkI1SUu0fhcs6CA06gGqauDbpU
                          mpM7VUX3";
};

Let’s check the authoritative server (192.168.1.13) for the correct key:

$ dig @192.168.1.13 example.com. DNSKEY +multiline

; <<>> DiG 9.10.1 <<>> @192.168.1.13 example.com. DNSKEY +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38451
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.       IN DNSKEY

;; ANSWER SECTION:
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAbluLK0k3dPKnsJNd5tGbO5bgh7WuXzaSDQVwi/q
                qPdCR65ZDiin0GTpL++B1iKYDP4rRL/s/2TMppI1fV63
                8f2SuhNQ9zYIuCo/FuHeJB7/DBQ03eJFvN1QHC0we2uU
                FrXazz8eT9nkI1SUu0fhcs6CA06gGqauDbpUmpM7VUX3
                ) ; ZSK; alg = RSASHA256; key id = 4974
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAb4N53kPbdRTAwvJT8OYVeVhQIldwppMy7KBJ+8k
                Uggx2PU3yP/qlq4Zjl0MMmqRiJhD/S+z9cJLNTZ9tHz1
                7aZQjFyGAyuU3DGW16xfMolcIn+c8TpPCzBOFhxk6jvO
                VLlz+Wgyi1ES+t29FjYYv5cVNRPmxXLRjlHFdO1DzX3N
                dmcUoZ+VVJCvaML9+6UpL/6jitNsoU8JHnxT9B2CGKcw
                N7VaK4l9Ida2BqY3/4UVqWzhj03/M5LK6cn1pEQbQMtY
                R0TNJURBKdK8bH663h98i23tVX0/85IsCVBL4Dd2boa3
                /7HPp7uZN1AjDvcRsOh1mqixwUGmVm1EskDIMy8=
                ) ; KSK; alg = RSASHA256; key id = 45319
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAfbc/0ESumm1mPVkm025PfHKHNYW62yx0wyLN5LE
                4DifN6FzIVSKSGdMOdq+z6vFGxzzjPDz7QZdeC6ttIUA
                Bo4tG7dDrsWK+tG5cm4vuylsEVbnnW5i+gFG/02+RYmZ
                ZT9AobXB5bVjfXl9SDBgpBluB35WUCAnK9WkRRUS08lf
                ) ; ZSK; alg = RSASHA256; key id = 60798
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAb3lVweaj4dA9dvmcwlkaVpJ4/3ccXbRjgV7jqh1
                p0REL8fI0Z42E9SdxdsdTi+2XYcmHDQYEoqwYh70t/4P
                4oObZFIUHl+hhKLdXQNZGtzT0xF60k527N9cHPddoXzg
                AXYBtGLlLMSJcV8s0rw/i+64xNGdRWpFRdo78RhJ5LU3
                1SAPUnhi3OvJgsOpBPntrSyX6iA5ZotitxZJNTqP+Jck
                lhPWFgFOBgdvWJ369BRlDGy/m8+pctypZq1hy7ZteHet
                r55/cLBXY1BEzz3Q8vLUnSOu5An8IF0v2Gt7hOyY3nqu
                bU5vjCbogLj1K5ySBAJbHcCPAFrPGSIfmRize+U=
                ) ; KSK; alg = RSASHA256; key id = 40327

;; Query time: 4 msec
;; SERVER: 192.168.1.13#53(192.168.1.13)
;; WHEN: Mon Nov 03 21:51:28 CST 2014
;; MSG SIZE  rcvd: 888

Did you spot the mistake? We have the correct key data in our configuration, but the key type was incorrect. In our configuration, the key was configured as a KSK (257), while the authoritative server indicates that it is a ZSK (256).

Chapter 6. Advanced Discussions

6.1. Key Generation

6.1.1. Can I Use the Same Key Pair for Multiple Zones?

Yes and no. Good security practice suggests that you should use unique key pairs for each zone, just like how you should have different passwords for your email account, social media login, and online banking credential. On a technical level, this is completely feasible, but then multiple zones are at risk when one key pair is compromised. If you have hundreds or thousands (or even hundreds of thousands) of zones to administer, a single key pair for all might be less error-prone to manage. You may choose to use the same approach to password management: use unique passwords for your bank accounts and shopping sites, but use a standard password for your not-very-important logins. So categorize your zones, high valued zones (or zones that have specific key rollover requirements) get their own key pairs, while other more “generic” zones can use a single key pair for easier management.

6.1.2. Do I Need Separate ZSK and KSK?

No, it is not required that you create two separate sets of keys, but you should, for operational ease. The DNSSEC protocol itself does not require two classes of keys, but for operational practicality, having two classes of keys make the life of a typical DNS(SEC) administrator’s life easier. One of the advantages of having separate ZSK and KSK is a better balance between security and ease of use: KSK can be stored in a secure and less accessible area, while ZSK is easily accessible for routine use. For more details and considerations on this topic, please refer to RFC 6781 Section 3 .

Please refer to Table 4.1, “ZSK KSK Comparison” for a comparison of how each of the keys are used.

6.1.3. Which Algorithm?

There are at least three algorithm choices for DNSSEC as of this writing (late 2014):

  • RSA
  • Digital Signature Algorithm (DSA)
  • Elliptic Curve DSA (ECDSA)

While all three are supported by BIND, RSA is the only one that is mandated to be implemented with DNSSEC, and at the time of this writing, is the most widely supported algorithm by both name servers and clients. For the near future, RSA/SHA-256 is the algorithm of choice, with RSA/SHA-1 being an alternative.

However, RSA is a little long in the tooth, and ECDSA is emerging as the next new cryptographic standard. In fact, the US federal government has recommended to stop using RSA altogether by September 2015, and migrate to using ECDSA or similar algorithms.

So for now, use RSA, but keep your eyes on emerging new standards or requirements. For details about rolling over DNSKEYs to a new algorithm, see Section 6.4.5, “DNSKEY Algorithm Rollovers”.

6.1.4. Key Sizes

The choice of key sizes is a classic issue of finding the balance between performance and security. The larger the key size, the longer it takes for an attacker to crack the key; but larger keys also means more resources are needed both when generating signatures (authoritative servers) and verifying signatures (recursive servers).

Of the two sets of keys, ZSK is used much more frequently. Whenever zone data changes, or when signatures expire, ZSK is used, so performance certainly is of a bigger concern. As for KSK, it is used less frequently, so performance is less of a factor, but its impact is bigger because of its role in signing other keys.

In this guide, the following key length were chosen for each set, with the recommendation that they be rotated more frequently for better security:

  • ZSK: RSA 1024 bits, rollover every year
  • KSK: RSA 2048 bits, rollover every five years

These should be the minimum key sizes one should choose.

If you choose to implement larger key sizes, keep in mind that larger key size results in larger DNS responses, and this may mean more load on network resources. Depending on network configuration, end users may even experience resolution failures due to the increased response sizes, as we have discussed in Section 3.5, “What’s EDNS All About (And Why Should I Care)?”.

6.2. Proof of Non-Existence (NSEC and NSEC3)

How do you prove that something does not exist? This zen-like question is an interesting one, and in this section we will provide an overview of how DNSSEC solves the problem.

Why is it even important to have authenticated denial of existence? Couldn’t we just send back a “hey, what you asked for does not exist”, and somehow generate a digital signature to go with it, proving it really is from the correct authoritative source? Well, the technical challenge of signing nothing aside, this solution has flaws, one of which is it gives an attacker a way to create the appearance of denial of service by replaying this message on the network.

We are going to use a little story, and tell it three different times to illustrate how proof of nonexistence works. In our story, we run a small company with three employees: Alice, Edward, and Susan. We list their names in a phone directory, and we hired a nameless intern to answer our phone calls.

If we followed the approach of giving back the same answer no matter what was asked, when people called and asked for “Bob”, our intern would simply answer: “Sorry, that person doesn’t work here, and to prove that I am not lying, here’s the signature: ‘deaf coffee beef'”. Now this is a legitimate answer, but since the signature doesn’t change, an attacker could record this message, and when the next person called in asking for Susan, she will hear the exact same message: “Sorry, that person doesn’t work here, and to prove that I am not lying, here’s the signature: ‘deaf coffee beef'”. And this answer is verifiable, since the magic signature (“deaf coffee beef” ) can be validated [4]. Now the attacker has successfully fooled the caller into thinking that Susan doesn’t work at our company, and might even be able to convince all callers that no one works at this company (no names exist).

To solve this problem, two different solutions were created, we will look at the first one, NSEC, next.

6.2.1. NSEC

The NSEC record is used to prove that something really does not exist, by providing the name before it, and the name after it. Using our tiny company example, this would be analogous to someone calling for Bob over the phone, and our nameless intern answered the phone with: “I’m sorry, that person doesn’t work here. The name before that is Alice, and the name after that is Edward”. Let’s say someone called in again for a non-existent person, Oliver, the answer would be: “I’m sorry, that person doesn’t work here. The name before that is Edward, and the name after that is Susan”. Another caller asked for Todd, and the answer would be: “I’m sorry, that person doesn’t work here. The name before that is Susan, and the name after that is Alice”.

So we end up with three NSEC records:

alice.example.com.  300 IN  NSEC    edward.example.com. A RRSIG NSEC
edward.example.com. 300 IN  NSEC    susan.example.com.  A RRSIG NSEC
susan.example.com.  300 IN  NSEC    alice.example.com.  A RRSIG NSEC

What if the attacker tried to use the same replay method described earlier? If someone called for Edward, none of the three answers would fit. If attacker played message #1, “I’m sorry, that person doesn’t work here. The name before it is Alice, and the name after it is Edward”, it is obviously false, since “Edward” is in the response; same for #2, Edward and Susan. As for #3, Edward does not fall in range after Susan or before Alice, and the caller can logically deduct that it was an incorrect answer.

In BIND inline signing, your zone data will be automatically sorted on the fly before generating NSEC records, much like how a phone directory is sorted.

Unfortunately, the NSEC solution has a few drawbacks, one of which is trivial “zone walking”. A curious person can keep calling back, and our nameless, gullible intern will keep divulging information about our employees. Imagine if the caller first asked: “Is Bob there?” and received back the names Alice and Edward. The caller can then call back again: “Is Edward A. there?”, and will get back Edward and Susan. Repeat the process enough times, the caller will eventually learn every name in our company phone directory. For many of you, this may not be a problem, since the very idea of DNS is similar to a public phone book: if you don’t want a name to be known publicly, don’t put it in DNS! Consider using DNS views (split DNS) and only display your sensitive names to a selective audience.

The second drawback of NSEC is a actually increased operational overhead: no opt-out mechanism for insecure child zones, this generally is a problem for parent zone operators dealing with a lot of insecure child zones, such as .com. To learn more about opt-out, please see Section 6.2.2.2, “NSEC3 Opt-Out”.

6.2.2. NSEC3

NSEC3 adds two additional features that NSEC does not have:

  1. No easy zone enumeration.
  2. Provides a mechanism for child zone to opt out.

Recall, in Section 6.2.1, “NSEC”, we provided a range of names to prove that something really does not exist. But as it turns out, even disclosing these ranges of names becomes a problem: this made it very easy for the curious minded to look at your entire zone. Not only that, unlike a zone transfer, this “zone walking” is more resource intensive. So how do we disclose something, without actually disclosing it?

The answer is actually quite simple, hashing functions, or one-way hashes. Without going into many details, think of it like a magical meat grinder. A juicy piece of ribeye steak goes in one end, and out comes a predictable shape and size of ground meat (hash) with a somewhat unique pattern. No matter how hard you try, you cannot turn the ground meat back into the juicy ribeye steak, that’s what we call a one-way hash.

NSEC3 basically runs the names through a one-way hash, before giving it out, so the recipients can verify the non-existence, without any knowledge of the actual names.

So let’s tell our little phone receptionist story for the third time, this time with NSEC3. This time, our intern is not given a list of actual names, he is given a list of “hashed” names. So instead of Alice, Edward, and Susan, the list he is given reads like this (hashes shortened for easier reading):

FSK5....  (produced from Edward)
JKMA.... (produced from Susan)
NTQ0.... (produced from Alice)

Then, the phone rings, someone’s asking for Bob again. Our intern takes the name Bob through a hash function, and the result is L8J2…, so he tells them on the phone: “I’m sorry, that person doesn’t work here. The name before that is JKMA…, and the name after that is NTQ0…”. There, we proved Bob doesn’t exist, without giving away any names! To put that into proper NSEC3 resource records, they would look like this (again, hashes shortened for display):

FSK5....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  JKMA... A RRSIG
JKMA....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  NTQ0... A RRSIG
NTQ0....example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF  FSK5... A RRSIG

Hashes and Privacy

Just because we employed one-way hash functions does not mean there’s no way for a determined individual to figure out what your zone data is. Someone could still gather all of your NSEC3 records and hashed names, and perform an offline brute-force attack by trying all possible combinations to figure out what the original name is. This would be like if someone really wanted to know how you got the ground meat, he could buy all cuts of meat and ground it up at home using the same model of meat grinder, and compare the output with the meat you gave him. It is expensive and time consuming (especially with real meat), but like everything else in cryptography, if someone has enough resources and time, nothing is truly private forever. If you are concerned about someone performing this type of attack on your zone data, see about adding salt as described in Section 6.2.2.3, “NSEC3 Salt”.

6.2.2.1. NSEC3PARAM

The above NSEC3 examples used four parameters: 1, 0, 10, and 1234567890ABCDEF. The rndc tool may be used to set the NSEC3 parameters for a zone; for example:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

1 represents the algorithm, 0 represents the opt-out flag, 10 represents the number of iterations, and 1234567890abcedf is the salt. Let’s look at how each one can be configured:

  • Algorithm: Not much of a choice here, the only defined value currently is 1 for SHA-1.
  • Opt-out: Set this to 1 if you want to do NSEC3 opt-out, which we will discuss in Section 6.2.2.2, “NSEC3 Opt-Out”.
  • Iterations: iterations defines the number of additional times to apply the algorithm when generating an NSEC3 hash. More iterations yields more secure results, but consumes more resources for both authoritative server sand validating resolvers. In the regard, we have similar considerations as we’ve seen in Section 6.1.4, “Key Sizes” of security versus resources.
  • Salt: The salt is a string of data expressed in hexadecimal, or a hyphen (`-‘) if no salt is to be used. We will learn more about salt in Section 6.2.2.3, “NSEC3 Salt”.

For example, to create an NSEC3 chain using the SHA-1 hash algorithm, no opt-out flag, 10 iterations, and a salt value of “FFFF”, use:

# rndc signing -nsec3param 1 0 10 FFFF example.com

To set the opt-out flag, 15 iterations, and no salt, use:

# rndc signing -nsec3param 1 1 15 - example.com

6.2.2.2. NSEC3 Opt-Out

One of the advantages of NSEC3 over NSEC is the ability for parent zones to publish less information about its child or delegated zones. Why would you ever want to do that? Well, if a significant number of your delegations are not yet DNSSEC-aware, meaning they are still insecure or unsigned, generating DNSSEC-records for their NS and glue records is not a good use of your precious name server resources.

The resources may not seem like a lot, but imagine in if you are the operator of busy top level domains such as .com or .net, with millions and millions of insecure delegated domain names, it quickly adds up. As of late 2014, less than 0.1% of all .com zones are signed. Basically, without opt-out, if you have 1,000,000 delegations, only 5 of which are secure, you still have to generate NSEC RRset for the other 999,995 delegations; with NSEC3 opt-out, you will have saved yourself 999.995 sets of records.

For most DNS administrators who do not manage a large number of delegations, the decision whether or not to use NSEC3 opt-out is probably not relevant.

To learn more about how to configure NSEC3 opt-out, please see Section 7.3.4, “NSEC3 Optout Recipe”.

6.2.2.3. NSEC3 Salt

As described in Section 6.2.2, “NSEC3”, while NSEC3 doesn’t put your zone data in plain public display, it is still not difficult for an attacker to collect all the hashed names, and perform an offline attack. All that is required is running through all the combinations to construct a database of plaintext names to hashed names, also known as a “rainbow table”.

There is one more features NSEC3 gives us to provide additional protection: salt. Basically, salt gives us the ability introduce further randomness into the hashed results. Whenever the salt is changed, any pre-computed rainbow table is rendered useless, and a new rainbow table must be re-computed. If the salt is changed from time to time, it becomes difficult to construct a useful rainbow table, thus difficult to walk the DNS zone data programmatically. How often you want to change your NSEC3 salt is up to you.

To learn more about what steps to take to change NSEC3, please see Section 7.3.3, “Changing NSEC3 Salt Recipe”.

6.2.3. NSEC or NSEC3?

So which one should you choose? NSEC or NSEC3? There is not really a single right answer here that fits everyone. It all comes down to your needs or requirements.

If you prefer not to make your zone easily enumerable, implementing NSEC3 paired with a new salt periodically will provide a certain level of privacy protection. However, someone could still randomly guess the names in your zone (such as ‘ftp’ or ‘www’), as in the traditional insecure DNS.

If you have many many delegations, and have a need for opt-out to save resources, NSEC3 is for you.

Other than that, using NSEC is typically a good choice for most zone administrators, as it relieves the authoritative servers from additional cryptographic operations NSEC3 requires, and NSEC is comparatively easier to troubleshoot than NSEC3.

6.3. Key Storage

6.3.1. Public Key Storage

The beauty of a public key cryptography system is that the public key portion can and should be distributed to as many people as possible. As the administrator, you may want to keep the public keys on an easily accessible file system for operational ease, but there is no need to securely store them, since both ZSK and KSK public keys are published in the zone data as DNSKEY resource records.

Additionally, a portion of the KSK public key is also uploaded to the parent zone (see Section 4.4, “Working with Parent Zone” for more details), and is published by the parent zone as DS records.

6.3.2. Private Key Storage

Ideally, private keys should be stored offline, in secure devices such as a smart card. Operationally, however, this creates certain challenges, since we need the private key to create RRSIG resource records, and it would be a hassle to bring the private key out of storage every time the zone file changes or when signatures expire.

A common approach to strike the balance between security and practicality is to have two sets of keys, a ZSK set, and a KSK set. ZSK private key is used to sign zone data, and can be kept online for ease of use; KSK private key is used to sign just the DNSKEY (the ZSK), it is used less frequently, and can be stored in a much more secure and restricted fashion.

For example, a KSK private key stored on a USB flash drive that is kept in a fireproof safe, only brought online once a year to sign a new pair of ZSK, combined with a ZSK private key stored on the network file-system available for routine use, maybe be a good a good balance between operational flexibility and security.

And if you need to change your keys, please see Section 6.4.1, “Key Rollovers”.

6.3.3. Hardware Security Modules (HSM)

A Hardware Security Module (HSM) comes in different shapes and sizes, but as the name indicates, it’s a physical device or devices, usually with some or all of the following features:

  • Tamper-resistant key storage
  • Strong random number generation
  • Hardware for faster cryptographic operations

Most organizations do not incorporate HSMs into their security practices due to cost and the added operational complexity.

BIND supports PKCS #11 (Public Key Cryptography Standard #11) for communication with HSMs and other cryptographic support devices. For more information on how to configure BIND to work with HSMs, please refer to the BIND 9 Administrator Reference Manual.

6.4. Key Management

Best practice for DNSSEC key management is to use different keys to sign zone data (ZSK) and DNSKEY data (KSK), as we’ve discussed in Section 6.1.2, “Do I Need Separate ZSK and KSK?”. Since these keys serve different functions, their timing and methods of rollovers are also different. In Section 4.6, “Maintenance Tasks”, we have broadly talked about how to perform a generic ZSK and KSK rollover. In this section, we will discuss two topics in more detail:

  1. Different considerations and methods of key rollovers.
  2. Key meta data and management

6.4.1. Key Rollovers

Generally speaking, ZSK should be rolled more frequently than KSK. In Section 4.6, “Maintenance Tasks”, we described at a very high level how to roll ZSK every year using key pre-publication (described below), and how to roll KSK every five years using double DS (also described below). Here, we show some other methods of rolling keys. To see examples of key rolling, please refer to Section 7.2, “Rollover Recipes”. For (far) deeper discussions and considerations on the topic of key rolling, check out https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing.

6.4.1.1. ZSK Rollover Methods

Generally speaking, ZSK is smaller in size (compared to KSK) for performance, but smaller keys take less time to break, thus ZSK should be changed, or rolled, more frequently. ZSK can be rolled in one of the following two ways:

  1. Pre-publication: Publish new ZSK into zone data before it is actually used. Wait at least one TTL so the world’s recursive servers know about both keys, then stop using the old key and generate new RRSIG using the new key. Wait at least another TTL, so the cached old key data is expunged from world’s recursive servers, before removing the old key.

    The benefit of the Pre-publication approach is it does not dramatically increase the zone size, but the duration of the rollover is longer. If not sufficient amount of time has passed after new ZSK is published, some resolvers may only have the old ZSK cached when the new RRSIG records are published, and validation may fail. This is the method that was described in Section 4.6.1, “ZSK Rollover” and Section 7.2.1, “ZSK Rollover Recipe”

  2. Double Signature: Publish new ZSK and new RRSIG, essentially double the size of the zone. Wait at least one TTL before removing the old ZSK and old RRSIG.

    The benefit of the Double Signature approach is that it is easier to understand and execute, but suffers from increased zone size (essentially double) during a rollover event.

6.4.1.2. KSK Rollover Methods

Rolling KSK requires interaction with the parent zone, so operationally this may be more complex than rolling ZSK. There are three methods of rolling KSK:

  1. Double-DS: the new DS record is published. After waiting for this change to propagate into caches, the KSK is changed. After a further interval during which the old DNSKEY RRset expires from caches, the old DS record is removed.

    Double-DS is the reverse of Double-KSK: the new DS is published at the parent first, then the KSK at the child is updated, then remove the old DS at the parent. The benefit is that the size of the DNSKEY RRset is kept to a minimum, but interactions with the parent zone is increased to two events. This is the method that is described in Section 4.6.2, “KSK Rollover” and Section 7.2.2, “KSK Rollover Recipe”.

  2. Double-KSK: the new KSK is added to the DNSKEY RRset which is then signed with both the old and new key. After waiting for the old RRset to expire from caches, the DS record in the parent zone is changed. After waiting a further interval for this change to be reflected in caches, the old key is removed from the RRset.

    Basically, the new KSK is added first at the child zone and being used to sign DNSKEY, then the DS record is changed, followed by the removal of the old KSK. Double-KSK limits the interaction with the parent zone to a minim, but for the duration of the rollover, the size of the DNSKEY RRset is increased.

  3. Double-RRset: the new KSK is added to the DNSKEY RRset which is then signed with both the old and new key, and the new DS record added to the parent zone. After waiting a suitable interval for the old DS and DNSKEY RRsets to expire from caches, the old DNSKEY and DS record are removed.

    Double-RRset is the fastest way to roll the KSK (shortest rollover time), but has the drawbacks of both of the other methods: a larger DNSKEY RRset and two interactions with the parent.

6.4.2. Key Management and Metadata

In Section 4.3.2.4, “auto-dnssec”, we alluded to that auto-dnssec is doing a lot of automation for us so we don’t have to, and we’ve also alluded to something called the key timing metadata. In fact, if you looked at your key file, it likely already has a section near the top that looks like this:

; Publish: 20141120094612 (Thu Nov 20 17:46:12 2014)
; Activate: 20141120094612 (Thu Nov 20 17:46:12 2014)

These are only two of the five metadata fields of a key. Below is a complete list of each of the metadata fields, and how it affects your key’s behavior:

  1. Publish: Sets the date on which a key is to be published to the zone. After that date, the key will be included in the zone but will not be used to sign it (yet). This is notifying validating resolvers that we are about to introduce a new key. By default, if not specified during creation time, this is set to the current time, meaning the key will be published as soon as named picks it up.
  2. Activate: Sets the date on which the key is to be activated. After that date, the key will be included in the zone and used to sign it. By default, if not specified during creation time, this is set to the current time, meaning the key will be used to sign data as soon as named picks it up.
  3. Revoke: Sets the date on which the key is to be revoked. After that date, the key will be flagged as revoked. It will be included in the zone and will be used to sign it. This is used to notify validating resolvers that this key is about to be removed or retired from the zone.
  4. Inactive: Sets the date on which the key is to become inactive. After that date, the key will still be included in the zone, but it will not be used to sign it. This sets the “expiration” or “retire” date for a key.
  5. Delete: Sets the date on which the key is to be deleted. After that date, the key will no longer be included in the zone, but it continues to exist on the file system or key repository.

You can set these metadata fields on a key pair as you’ve seen in Section 4.6.1, “ZSK Rollover” using commands such as dnssec-keygen or dnssec-settime.

Table 6.1. Key Metadata Comparison

Metadata Included in Zone File? Used to Sign Data? Purpose
Publish Yes No Introducing a key soon to be active
Activate Yes Yes Activation date for new key
Revoke Yes Yes Notifying a key soon to be retired
Inactive Yes No Inactivate or retire a key
Delete No No Deletion or removal of key from zone


6.4.2.1. Manual Key Management and Signing

This guide is intended as an introductory to DNSSEC deployment using BIND. Since BIND comes with a set of features to automate key loading and signing, that is the recommended configuration for readers of this document. In this section, we will only briefly cover tools and commands to manually load keys and manually sign zone data, but not go into great details.

The directive auto-dnssec maintain makes named check for new keys and load them automatically on an interval. If you wish to not automate this process, you could opt to change it to auto-dnssec off. This makes all key management manual, and to load new keys, you will need to execute the command rndc loadkeys example.com.

To manually sign the zone, first, you need to edit the zone file to make sure the proper DNSKEY entries are included in your zone file, then use the command dnssec-signzone as such:

# cd /etc/bind/keys/example.com/
# dnssec-signzone -A -t -N INCREMENT -o example.com -f /etc/bind/db/example.com.signed.db \
> /etc/bind/db/example.com.db Kexample.com.+008+17694.key Kexample.com.+008+06817.key
Verifying the zone using the following algorithms: RSASHA256.
Zone fully signed:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                      ZSKs: 1 active, 0 stand-by, 0 revoked
/etc/bind/db/example.com.signed.db
Signatures generated:                       17
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:            0
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.046
Signatures per second:                 364.634
Runtime in seconds:                      0.055

The -o switch explicitly defines the domain name (example.com in this case), -f switch specifies the output file name. The second line has 3 parameters, they are the unsigned zone name (/etc/bind/db/example.com.db), ZSK, and KSK file names. This generated a plain text file /etc/bind/db/example.com.signed.db, which you can verify for correctness.

Finally, you’ll need to update named.conf to load the signed version of the zone, so it looks something like this:

zone "example.com" IN {
    type master;
    file "db/example.com.signed.db";
};

You will need to re-sign periodically as as well as every time the zone data changes.

6.4.3. How Long Do I Wait Before Deleting Old Data?

If you have followed the examples described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones” and Section 4.6, “Maintenance Tasks”, old keys and old signatures are automatically removed from the zone.

However, it is still good to discuss why bother waiting a period of time before removing any old data, be it DNSKEY or RRSIG. The goal here is to not “orphan” anyone out there who may be getting a cached answer, and the information to verify that cached answer doesn’t exist anymore. For example, if you chose to pre-publish your ZSK, but did not wait long enough before removing the old ZSK, you’re running with the risk that there may be users out there receiving the old RRSIG out of cache, but they are unable to verify the cached old RRSIG because the old ZSK has already been removed. To these users, the domain names would fail validation, until the cached RRSIG entries expire, and their validating resolver retrieves the new RRSIG signed by the new ZSK.

In Section 4.6, “Maintenance Tasks”, we recommended using a very generic and easy to remember 30 days as the amount of time to wait, partly because 30 days is also the default validity time for RRSIG. If you decide to manage your own zone signing and record removing, you should wait at least the duration of your old record’s TTL before attempting to removing it from the zone. It is probably better to err on the safe side and leave the old data in the zone a little longer.

Note

One of the worst things to happen during a rollover is to “orphan” old keys, by deleting it too soon from the zone. This will result in the world’s recursive servers come asking “hey, do you have the key(s) for these older signatures?” and not get an answer to satisfy their needs. The recursive servers would have to fail the validation, and the users may think you zone has been compromised because the keys and signatures to match up. This is why it is a good idea to wait a period of time in-between each phase of the key rollover, to ensure that not only new information has propogated to the world, but also that old information that was previously published to the world have expired from whoever has been caching them. This is why in this document we have chosen a very conservative period of 30 days. If you have unusually long TTL or signature expirations, it may be wise to change the rollover schedule accordingly.

6.4.4. Emergency Key Rollovers

Keys are generally rolled at a regular schedule (that is, if you choose to roll them at all). But sometimes, you may have to rollover keys out-of-schedule due to a security incident. The aim of an emergency rollover is re-sign the zone with a new key as soon as possible, because when a key is suspected of being compromised, the malicious attacker (or anyone who has access to the key) could impersonate you, and trick other validating resolvers into believing that they are receiving authentic, validated answers.

During an emergency rollover, you would follow the same operational procedures as described in Section 7.2, “Rollover Recipes”, with the added task of reducing the TTL of current active (possibly compromised) DNSKEY RRset, in attempt to phase out the compromised key faster before the new key takes effect. The time frame should be significantly reduced from the 30-days-apart example, since you probably don’t want to wait up to 60 days for the compromised key to be removed from your zone.

Another method is to always carry a spare key with you at all times. You could always have a second key (pre)published (and hopefully this one was not compromised the same time as the first key), so if the active key is compromised, you could save yourself some time to immediately activate the spare key, and all the validating resolvers should already have this spare key cached, thus saving you some time.

With KSK emergency rollover, you would have to also consider factors related to your parent zone, such as how quickly they can remove the old DS record and published the new ones.

As usual, there is a lot more to consider when it comes to emergency key rollovers. For more in-depth considerations, please check out https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing.

6.4.5. DNSKEY Algorithm Rollovers

From time to time new digital signature algorithms with improved security are introduced, and it may be desirable for administrators to roll over DNSKEYs to a new algorithm, e.g. from RSASHA1 (algorithm 5 or 7) to RSASHA256 (algorithm 8). The algorithm rollover must be done with care in a stepwise fashion to avoid breaking DNSSEC validation.

As with other DNSKEY rollovers, when the zone is of type master, an algorithm rollover can be accomplished using dynamic updates or automatic key rollovers. For zones of type slave, only automatic key rollovers are possible, but the dnssec-settime utility can be used to control the timing of such.

In any case the first step is to put DNSKEYs using the new algorithm in place. You must generate the K* files for the new algorithm and put them in the zone’s key directory where named can access them. Take care to set appropriate ownership and permissions on the keys. If the auto-dnssec zone option is set to maintain, named will automatically sign the zone with the new keys based on their timing metadata when the dnssec-loadkeys-interval elapses or you issue the rndc loadkeys command. Otherwise for zones of type master, you can use nsupdate to add the new DNSKEYs to the zone. This will cause named to use them to sign the zone. For zones of type slave, e.g. on a bump-in-the-wire inline signing server, nsupdate cannot be used.

Once the zone has been signed by the new DNSKEYs, you must inform the parent zone and any trust anchor repositories of the new KSKs, e.g. you might place DS records in the parent zone through your DNS registrar’s website.

Before starting to remove the old algorithm from a zone, you must allow the maximum TTL on its DS records in the parent zone to expire. This will assure that any subsequent queries will retrieve the new DS records for the new algorithm. After the TTL has expired, you can remove the DS records for the old algorithm from the parent zone and any trust anchor repositories. You must then allow another maximum TTL interval to elapse so that the old DS records disappear from all resolver caches.

The next step is to remove the DNSKEYs using the old algorithm from your zone. Again this can be accomplished using nsupdate to delete the old DNSKEYs (master zones only) or by automatic key rollover when auto-dnssec is set to maintain. You can cause the automatic key rollover to take place immediately by using the dnssec-settime utility to set the Delete date on all keys to any time in the past. (See dnssec-settime -D <date/offset> option.)

After adjusting the timing metadata, the rndc loadkeys command will cause named to remove the DNSKEYs and RRSIGs for the old algorithm from the zone. Note also that with the nsupdate method, removing the DNSKEYs also causes named to remove the associated RRSIGs automatically.

Once you have verified that the old DNSKEYs and RRSIGs have been removed from the zone, the final step (optional) is to remove the key files for the old algorithm from the key directory.

6.5. Other Topics

6.5.1. DNSSEC and Dynamic Updates

Dynamic DNS (DDNS) actually is independent of DNSSEC. DDNS provides a mechanism other than editing the zone file or zone database, to edit DNS data. Most clients and DNS servers have the capability to handle dynamic updates, and DDNS can also be integrated as part of your DHCP environment.

When you have both DNSSEC and dynamic updates in your environment, updating zone data works the same way as with traditional (insecure) DNS: you can use rndc freeze before editing the zone file, and rndc thawwhen you have finished editing, or you could use the command nsupdate to add, edit, or remove records like this:

$ nsupdate
> server 192.168.1.13
> update add xyz.example.com. 300 IN A 1.1.1.1
> send
> quit

The examples provided in this guide will make named automatically re-sign the zone whenever its content has changed. If you decide to sign your own zone file manually, you will need to remember to executed the dnssec-signzone whenever your zone file has been updated.

As far as system resources and performance is concerned, be mindful that when you have a DNSSEC zone that changes frequently, every time the zone changes, your system is executing a series of cryptographic operations to (re)generate signatures and NSEC or NSEC3 records.

6.5.2. DNSSEC and Inline Signing

ISC introduces the “inline-signing” option with the release of BIND 9.9, which allows named to sign zones completely transparently. named does this by automatically creating an internal version of the zone that is signed on the fly, and only the signed version of the zone is presented to queries. The unsigned version of the zone file is untouched on the file system, but not served.

This features simplifies DNSSEC deployment, below are two common scenarios of how this feature can be used:

  1. You administer the master server, with zone transfers to other slave servers: This is what most examples in this guide describes, you have control over the master server, you you can follow the instruction inSection 4.1, “Easy Start Guide for Signing Authoritative Zones” to generate key pairs and modify named.conf. A signed version of the zone is either generated on the fly by inline-signing, and zone transfers will take care of synchronizing the signed zone data to all slave name servers.
  2. You cannot easily modify the master sever configuration, but still would like all slave servers to get DNSSEC zones: you can setup a “middle box” that all slave name servers transfer data from, and your middle box gets its zone from the master server. You do not need to modify the master name server configuration at all, on the middle box, set it up to have inline signing enabled, whenever your middle box receives zone transfer (unsigned) from the master server, a signed version is generated on the fly, and this is the version that will be transferred out to the other slave name servers.

For more details and configuration examples on Inline Signing, please see Section 7.1, “Inline Signing Recipes”.

6.5.3. DNSSEC Look-aside Validation (DLV)

First of all, if you are running older versions of BIND9 on your validating resolver, specifically, older than 9.4.3-P2, 9.5.1-P2, or 9.6.1, dnssec-lookaside is not supported.

So what is it? DNSSEC Look-aside Validation (DLV) is an extension to the DNSSEC protocol. It is designed to assist in early DNSSEC adoption by simplifying the configuration of recursive servers and lessen the burden of key management for the administrators. Without DLV, in the absence of a fully signed path from root to a zone, administrators wishing to enable DNSSEC validation would have to configure and maintain multiple trust anchors or managed keys in their configuration.

DLV removes the need for manual key management by identifying a trusted repository through which those keys can be securely retrieved by the validating resolver when it needs them. Basically, someone else (in this case, ISC) is performing the tedious task of trust anchor management, and your validating resolver just needs to trust that someone else (in this case, ISC) is doing a good job maintaining these trust anchors for you.

To enable DLV on your validating resolver, place this line in your configuration file and reload named:

dnssec-lookaside auto;

Warning

ISC plans to discontinue the DLV service at some point in the future, as DNSSEC deployment is nearing a more mature stage where most top level domains are signed and more and more registrars are DNSSEC-ready. If you are currently relying on DLV service provided by ISC, be aware that the service will not be available forever.

6.5.4. DNSSEC on Private Networks

Before we discuss DNSSEC on private networks, let’s clarify what we mean by private networks. In this section, private networks really refers to a private or internal DNS view. Most DNS products offer the ability to have different version of DNS answers, depending on the origin of the query. This feature is often called DNS views or split DNS, and is most commonly implemented as an “internal” versus an “external” setup.

For instance, your organization may have a version of example.com that is offered to the world, and its names most likely resolves to publicly reachable IP addresses. You may also have an internal version of example.comthat is only accessible when you are on the company’s private networks or via a VPN connection. These private networks typical fall under 10.0.0.0/8, 172.16.0.0.0/12, or 192.168.0.0.0/16 for IPv4.

So what if you want to offer DNSSEC for your internal version of example.com? This is actually a more involving question, and we can only cover this topic briefly in this document.

Deploying DNSSEC in this context is possible. Because private networks are usually trusted, there may be less need to worry about someone hijacking your DNS traffic. This is commonly known as the “last mile” in DNS delivery. If you wish to deploy DNSSEC on your private networks, here are some scenarios to consider:

  1. If your name server is configured as both the validating resolver and the internal authoritative server, the answers returned to your clients will not be validated at all. This is because the answer is coming directly from the authoritative server, thus the Authoritative Answer (aa) bit is set, and by definition, it is not validated. What this means is, to a regular client making the query, the secure authoritative answer looks exactly the same as the insecure authoritative answer.
  2. If you have two name server instances running, one acting as the validating resolver, and one acting as the internal authoritative name server, it is possible to actually validate answers, provided that you have installed the trust anchor(s) necessary for your internal zones on the validating resolver. If no trust anchors are installed, your validating resolver will go out to root, and attempt to validate internal answers against external authorities (and fail). In this setup, the client gets back the Authenticated Data (ad) bit when querying against the validating resolver.
  3. DNSSEC is designed to protect the communication between the client and the nameserver, however there are few applications or stub resolver libraries that take advantage of this. DNSSEC can help with last mile security in a managed environment, by deploying validating resolvers (such as BIND) on client machines.

In addition, early efforts have concentrated on getting DNSSEC deployed between authoritative servers and recursive servers as that is a prerequisite for working DNSSEC between the recursive server and the application. These efforts also provide a degree of protection for applications that are not DNSSEC-aware.

6.5.5. Introduction to DANE

With your DNS infrastructure now secured with DNSSEC, information can now be stored in DNS and its integrity and authenticity can be proved. One of the ne features that takes advantage of this is the DNS-Based Authentication of Named Entities, or DANE. Below is a list of features currently being developed and tested by the DANE community:

  • Use DANE as a verification mechanism to verify SSL/TLS certificates received over HTTPS for added security. You can see a live demonstration here: http://dane.verisignlabs.com/.
  • Store self-signed X.509 certificates, bypass having to pay a third party (such as a Certificate Authority) to sign the certificates.
  • Integrate with Mail Transfer Agents (MTA) to provide seamless email encryption.

DANE is an exciting area for DNS administrators, if you would like to learn more about the standards being proposed or new features being discussed, check out the DANE working group:https://datatracker.ietf.org/wg/dane/charter/. You can also check out Section 7.5, “Self-signed Certificate Recipe”.

6.6. Disadvantages of DNSSEC

DNSSEC, like many things in this world, is not perfect and without its own problems. Below are a few challenges and disadvantages that DNSSEC faces.

  1. Increased, well, everything: With DNSSEC, signed zones are larger, thus taking up more disk space; for DNSSEC-aware servers, the additional cryptographic computation usually results in increased system load; and the network packets are bigger, possibly putting more strains on the network infrastructure.
  2. Different security considerations: DNSSEC addresses many security concerns, most notably cache poisoning. But at the same time, it may introduce a set of different security considerations, such as amplification attack and zone enumeration through NSEC. These new concerns are still being identified and addressed by the Internet community.
  3. More complexity: If you have read this far, you probably already concluded this yourself. With additional resource records, keys, signatures, rotations, DNSSEC adds a lot more moving pieces on top of the existing DNS machine. The job of the DNS administrator changes, as DNS becomes the new secure repository of everything from spam avoidance to encryption keys, and the amount of work involved to troubleshoot a DNS-related issue becomes more challenging.
  4. Increased fragility: The increased complexity means more opportunities for things to go wrong. In the absence of DNSSEC, DNS was essentially “add something to the zone and forget”. With DNSSEC, each new component – re-signing, key rollover, interaction with parent zone, key management – adds more scope for error. It is entirely possible that the failure to validate a name is down to errors on the part of one or more zone operators rather than the result of a deliberate attack on the DNS.
  5. New maintenance tasks: Even if your new secure DNS infrastructure runs without any hiccups or security breaches, it still requires regular attention, from re-signing to key rollovers. While most of these can be automated, some of the tasks, such as KSK rollover, remain manual for the time being.
  6. Not enough people are using it today: while it’s estimated as of late 2014, that roughly 12% of the global Internet DNS traffic is validating [5] , that doesn’t mean that many of the DNS zones are actually signed. What this means is, if you signed your company’s zone today, only less than 15% of the Internet users are taking advantage of this extra security. It gets worse, with less than 1% of the .com domains signed, if you enabled DNSSEC validation today, it’s not likely to buy you or your users a whole lot more protection, until these popular domains names decide to sign their zones.

The last point may have more impact than you realize. Consider this: HTTP and HTTPS traffic make up majority of the web. While you may have secured your DNS infrastructure through DNSSEC, if your web hosting is outsourced to a third party that does not yet support DNSSEC in their own domain, or if your web page loads contents and components from insecure domains, the end users may experience validation problems when trying to access your web page. For example, although I may have signed the zone isc.org, but my web address http://www.isc.org is actually a CNAME to 96d719dc5612761de516fc.random-cloud-provider.com. As long asrandom-cloud-provider.com remains an insecure DNS zone, users cannot fully validate everything when they visit my web page and could be redirected elsewhere by a cache poisoning attack.


[4] Actually it cannot be verified, read Section 3.3.3, “How are Answers Verified?” to review why this would not work.

[5] This percentage an overly simplified average provided by Geoff Huston in an interview dated September 2014. The interview video can be found online at http://www.internetsociety.org/deploy360/blog/2014/09/video-geoff-huston-what-if-everyone-did-dnssec-apnic-38/. The research that includes more details, including percentage of DNSSEC traffic by country or by network, is available at http://www.potaroo.net/ispcol/2014-07/measure.html.

Chapter 7. Recipes

This chapter provides step-by-step examples of some common configurations.

7.1. Inline Signing Recipes

There are two recipes here, the first shows an example of using inline signing on the master server, which is what we have covered in this guide thus far; the second example shows how to setup a “bump in the wire” between the hidden master and the slave servers to seamlessly sign the zone on the fly.

7.1.1. Master Server Inline Signing Recipe

In this recipe, our servers are illustrated as shown in Figure 7.1, “Inline Signing Recipe #1”: we have a master server 192.168.1.1 and three slave servers (192.168.1.2, 192.168.1.3, and 192.168.1.4) that receive zone transfers. In order to get the zone signed, we need to reconfigure the master server, as described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”. Once reconfigured, a signed version of the zone is generated on the fly by inline-signing, and zone transfers will take care of synchronizing the signed zone data to all slave name servers, without configuration or software changes on the slave servers.

Figure 7.1. Inline Signing Recipe #1

Inline Signing Recipe #1


Below is what the named.conf looks like on the master server, 192.168.1.1:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

On the slave servers, named.conf does not need to be updated, and it looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.1; };
};

In fact, slave servers do not even need to be running BIND, it could be running any other DNS product that has DNSSEC support.

7.1.2. “Bump in the Wire” Inline Signing Recipe

In this recipe, we are taking advantage of the power of inline signing by placing an additional name server 192.168.1.5 between the hidden master (192.168.1.1) and the DNS slaves (192.168.1.2, 192.168.1.3, and 192.168.1.4). The additional name server 192.168.1.5 acts as a “bump in the wire”, taking unsigned zone from the hidden master on one end, and sending out signed data on the other end to the slave name servers. The steps described in this recipe may be used as part of the DNSSEC deployment strategy, since it requires minimal changes made to the existing hidden DNS master and DNS slaves.

Figure 7.2. Inline Signing Scenario #2

Inline Signing Scenario #2


It is important to remember that 192.168.1.1 in this case is a hidden master not exposed to the world, it must not be listed in the NS RRset. Otherwise the world will get conflicting answers, unsigned answers from the hidden master, and signed answers from the other name servers.

The only configuration change needed on the hidden master 192.168.1.1 is to make sure it allows our middle box to perform a zone transfer:

zone "example.com" IN {
    ...
    allow-transfer { 192.168.1.5; };
    ...
};

On the middle box 192.168.1.5, all the tasks described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones” still need to be performed, such as generating key pairs and uploading information to parent zone. This server is configured as slave to the hidden master 192.168.1.1, receiving the unsigned data, and then using keys accessible to this middle box, sign data on the fly, and send out the signed data via zone transfer to the other three DNS slaves. Its named.conf looks like this:

zone example.com {
    type slave;
    masters { 192.168.1.1; };
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { 192.168.1.2; 192.168.1.3; 192.168.1.4; };
};

Finally, on the three slave servers, configuration should be updated to receive zone transfer from 192.168.1.5 (middle box) instead of 192.168.1.1 (hidden master). If using BIND, the named.conf looks like this:

zone "example.com" IN {
    type slave;
    file "db/example.com.db";
    masters { 192.168.1.5; };   # this was 192.168.1.1 before!
};

7.2. Rollover Recipes

7.2.1. ZSK Rollover Recipe

This recipe covers how to perform a ZSK rollover using what is known as the Pre-Publication method. For other ZSK rolling methods, please see Section 6.4.1.1, “ZSK Rollover Methods” in Chapter 6, Advanced Discussions.

Below is the timeline for a ZSK rollover to occur on January 1st, 2015:

  1. December 1st, 2014, a month before rollover

    • Generate new ZSK
    • Add DNSKEY for new ZSK to zone
  2. January 1st, 2015, day of rollover

    • New ZSK used to replace RRSIGs for the bulk of the zone
  3. February 1st, 2015

    • Remove old ZSK DNSKEY RRset from zone
    • DNSKEY signatures made with KSK are changed

The current active ZSK has the ID 17694 in this example. For more information on key management (such as what inactive date is, and why 30 days for example), please see Section 6.4, “Key Management”.

7.2.1.1. One Month Before ZSK Rollover

On December 1st, 2014, a month before the planned rollover, you should change the parameters on the current key (17694) to become inactive on January 1st, 2015, and be deleted from the zone on February 1st, 2015, as well as generate a successor key (51623):

# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20150101 -D 20150201 Kexample.com.+008+17694
./Kexample.com.+008+17694.key
./Kexample.com.+008+17694.private
# dnssec-keygen -S Kexample.com.+008+17694
Generating key pair..++++++ ...........++++++ 
Kexample.com.+008+51623

The first command gets us into the key directory /etc/bind/keys/example.com/, where keys for example.com are stored.

The second dnssec-settime sets an inactive (-I) date of January 1st, 2015, and a deletion (-D) date of February 1st, 2015 for the current ZSK (Kexample.com.+008+17694).

Then the third command dnssec-keygen creates a successor key, using the exact same parameters (algorithms, key sizes, etc.) as the current ZSK. The new ZSK created in our example is Kexample.com.+008+51623.

Don’t forget to make sure the successor keys are readable by named.

You can see in named‘s logging messages informing you when the next key checking event is scheduled to occur, the frequency of which can be controlled by dnssec-loadkeys-interval. The log message looks like this:

zone example.com/IN (signed): next key event: 01-Dec-2014 00:13:05.385

And you can check the publish date of the key by looking at the key file:

# cd /etc/bind/keys/example.com
# cat Kexample.com.+008+51623.key 
; This is a zone-signing key, keyid 11623, for example.com.
; Created: 20141130160024 (Mon Dec  1 00:00:24 2014)
; Publish: 20141202000000 (Tue Dec  2 08:00:00 2014)
; Activate: 20150101000000 (Thu Jan  1 08:00:00 2015)
...

Since the publish date is set to the morning of December 2nd, the next morning you will notice that your zone has gained a new DNSKEY record, but the new ZSK is not yet being used to generate signatures. Below is the abbreviated output with shortened DNSKEY and RRSIG when querying the authoritative name server, 192.168.1.13:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAcWDps...lM3NRn/G/R
                ) ; KSK; alg = RSASHA256; key id = 6817
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAbi6Vo...qBW5+iAqNz
                ) ; ZSK; alg = RSASHA256; key id = 51623
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAcjGaU...0rzuu55If5
                ) ; ZSK; alg = RSASHA256; key id = 17694
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150101000000 20141201230000 6817 example.com.
                LAiaJM26T7...FU9syh/TQ= )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150101000000 20141201230000 17694 example.com.
                HK4EBbbOpj...n5V6nvAkI= )
...

And for good measures, let’s take a look at the SOA record and its signature for this zone. Notice the RRSIG is signed by the current ZSK 17694. This will come in handy later when you want to verify whether or not the new ZSK is in effect:

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

...
;; ANSWER SECTION:
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014120102 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20141230160109 20141130150109 17694 example.com.
                YUTC8rFULaWbW+nAHzbfGwNqzARHevpryzRIJMvZBYPo
                NAeejNk9saNAoCYKWxGJ0YBc2k+r5fYq1Mg4ll2JkBF5
                buAsAYLw8vEOIxVpXwlArY+oSp9T1w2wfTZ0vhVIxaYX
                6dkcz4I3wbDx2xmG0yngtA6A8lAchERx2EGy0RM= )

These are all the manual tasks you need to perform for a ZSK rollover. If you have followed the configuration examples in this guide of using inline-signing and auto-dnssec, everything else is automated for you.

7.2.1.2. Day of ZSK Rollover

On the actual day of the rollover, although there is technically nothing for you to do, you should still keep an eye on the zone to make sure new signatures are being generated by the new ZSK (51623 in this example). The easiest way is to query the authoritative name server 192.168.1.13 for the SOA record like you did a month ago:

$ dig @192.168.1.13 example.com. SOA +dnssec +multiline

...
;; ANSWER SECTION:
example.com.        600 IN SOA ns1.example.com. admin.example.com. (
                2014112011 ; serial
                1800       ; refresh (30 minutes)
                900        ; retry (15 minutes)
                2419200    ; expire (4 weeks)
                300        ; minimum (5 minutes)
                )
example.com.        600 IN RRSIG SOA 8 2 600 (
                20150131000000 20141231230000 51623 example.com.
                J4RMNpJPOmMidElyBugJp0RLqXoNqfvo/2AT6yAAvx9X
                zZRL1cuhkRcyCSLZ9Z+zZ2y4u2lvQGrNiondaKdQCor7
                uTqH5WCPoqalOCBjqU7c7vlAM27O9RD11nzPNpVQ7xPs
                y5nkGqf83OXTK26IfnjU1jqiUKSzg6QR7+XpLk0= )
...

As you can see, the signature generated by the old ZSK (17694) disappeared, replaced by a new signature generated from the new ZSK (51623).

Life Time of the Signatures

Not all signatures will disappear magically on the same day, depending on when each one is generated. Worst case scenario is that a new signature could have been signed by the old ZSK (17695) moments before it was deactivated, thus the signature could live for almost 30 more days, all the way up to right before February 1st.

This is why it is important that you should keep the old ZSK in the zone for a little bit longer and not delete it right away.

7.2.1.3. One Month After ZSK Rollover

Again, technically there should be nothing you need to do on this day, but it doesn’t hurt to verify that the old ZSK (17694) is now completely gone from your zone. named will not touch Kexample.com.+008+17694.privateand Kexample.com.+008+17694.key on your file system. Running the same dig command for DNSKEY should suffice:

$ dig @192.168.1.13 example.com. DNSKEY +multiline +dnssec

...
;; ANSWER SECTION:
example.com.        600 IN DNSKEY 257 3 8 (
                AwEAAcWDps...lM3NRn/G/R
                ) ; KSK; alg = RSASHA256; key id = 6817
example.com.        600 IN DNSKEY 256 3 8 (
                AwEAAdeCGr...1DnEfX+Xzn
                ) ; ZSK; alg = RSASHA256; key id = 51623
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150203000000 20150102230000 6817 example.com.
                KHY8P0zE21...Y3szrmjAM= )
example.com.        600 IN RRSIG DNSKEY 8 2 600 (
                20150203000000 20150102230000 51623 example.com.
                G2g3crN17h...Oe4gw6gH8= )
...

Congratulations, the ZSK rollover is complete! As for the actual key files (the .key and .private files), they may be deleted at this point, but it’s not required.

7.2.2. KSK Rollover Recipe

This recipe describes how to perform KSK rollover using the Double-DS method. For other KSK rolling methods, please see Section 6.4.1.2, “KSK Rollover Methods” in Chapter 6, Advanced Discussions. The registrar used in this recipe is GoDaddy . Also for this recipe, we are keeping the number of DS records down to just one per active set using just SHA-1, for the sake of better clarity, although in practice most zone operators choose to upload 2 DS records as we have shown in Section 4.4, “Working with Parent Zone”. For more information on key management (such as what inactive date is, and why 30 days for example), please see Section 6.4, “Key Management”.

Below is the timeline for a KSK rollover to occur on January 1st, 2015:

  1. December 1st, 2014, a month before rollover

    • Change timer on current KSK
    • Generate new KSK and DS records
    • Add DNSKEY for new KSK to zone
    • Upload new DS records to parent zone
  2. January 1st, 2015, day of rollover

    • Use new KSK to sign all DNSKEY RRset, this generates new RRSIGs
    • Add new RRSIGs to the zone
    • Remove RRSIG for old ZSK from zone
    • Start using new KSK to sign DNSKEY
  3. February 1st, 2015

    • Remove old KSK DNSKEY from zone
    • Remove old DS records from parent zone

The current active KSK has the ID 248282, and this is the DS record that has already been published by the parent zone:

# dnssec-dsfromkey -a SHA-1 Kexample.com.+007+24828.key
example.com. IN DS 24828 7 1 D4A33E8DD550A9567B4C4971A34AD6C4B80A6AD3

7.2.2.1. One Month Before KSK Rollover

On December 1st, 2014, a month before the planned rollover, you should change the parameters on the current key to become inactive on January 1st, 2015, and be deleted from the zone on February 1st, 2015, as well as generate a successor key (23550). Finally, you should generate a new DS record based on the new key 23550:

# cd /etc/bind/keys/example.com/
# dnssec-settime -I 20150101 -D 20150201 Kexample.com.+007+24828
./Kexample.com.+007+24848.key
./Kexample.com.+007+24848.private
# dnssec-keygen -S Kexample.com.+007+24848
Generating key pair.......................................................................................++ ...................................++ 
Kexample.com.+007+23550
# dnssec-dsfromkey -a SHA-1 Kexample.com.+007+23550.key
example.com. IN DS 23550 7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB

The first command gets us into the key directory /etc/bind/keys/example.com/, where keys for example.com are stored.

The second dnssec-settime sets an inactive (-I) date of January 1st, 2015, and a deletion (-D) date of February 1st, 2015 for the current KSK (Kexample.com.+007+24848).

Then the third command dnssec-keygen creates a successor key, using the exact same parameters (algorithms, key sizes, etc.) as the current KSK. The new key pair created in our example is Kexample.com.+007+23550.

The fourth and final command dnssec-dsfromkey creates a DS record from the new KSK (23550), using SHA-1 as the digest type. Again, in practice most people generate two DS records for both supported digest types (SHA-1 and SHA-256), but for our example here we are only using one to keep the output small and hopefully clearer.

Don’t forget to make sure the successor keys are readable by named.

You can see in syslog the messages informing you when the next key checking event is, and it looks like this:

zone example.com/IN (signed): next key event: 01-Dec-2014 00:13:05.385

And you can check the publish date of the key by looking at the key file:

# cd /etc/bind/keys/example.com
# cat Kexample.com.+007+23550.key
; This is a key-signing key, keyid 23550, for example.com.
; Created: 20141130160024 (Mon Dec  1 00:00:24 2014)
; Publish: 20141202000000 (Tue Dec  2 08:00:00 2014)
; Activate: 20150101000000 (Thu Jan  1 08:00:00 2015)
...

Since the publish date is set to the morning of December 2nd, the next morning you will notice that your zone has gained a new DNSKEY record based on your new KSK, but no corresponding RRSIG yet. Below is the abbreviated output with shortened DNSKEY and RRSIG when querying the authoritative name server, 192.168.1.13:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.   300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAeTJ+w...O+Zy9j0m63
                ) ; KSK; alg = NSEC3RSASHA1; key id = 24828
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.   300 IN RRSIG DNSKEY 7 2 300 (
                20141206125617 20141107115617 24828 example.com.
                4y1iPVJOrK...aC3iF9vgc= )
example.com.   300 IN RRSIG DNSKEY 7 2 300 (
                20141206125617 20141107115617 29747 example.com.
                g/gfmPjr+y...rt/S/xjPo= )

...

Any time after you have generated the DS record, you could upload it, you don’t have to wait for the DNSKEY to be published in your zone, since this new KSK is not active yet. You could choose to do it immediately after the new DS record has been generated on December 1st, or you could wait until the next day after you have verified that the new DNSKEY record is added to the zone. Below are the screenshots from using GoDaddy’s web-based interface to add a new DS record.

  1. After logging in, click the green “Launch” button next to the domain name you want to manage.

    Figure 7.3. Upload DS Record Step #1

    Upload DS Record Step #1
  2. Scroll down to the “DS Records” section and click Manage.

    Figure 7.4. Upload DS Record Step #2

    Upload DS Record Step #2
  3. A dialog appears, displaying the current key (24828). Click “Add DS Record”.

    Figure 7.5. Upload DS Record Step #3

    Upload DS Record Step #3
  4. Enter the Key ID, algorithm, digest type, and the digest, then click “Next”.

    Figure 7.6. Upload DS Record Step #4

    Upload DS Record Step #4
  5. Address any errors and click “Finish”.

    Figure 7.7. Upload DS Record Step #5

    Upload DS Record Step #5
  6. Both DS records are shown. Click “Save”.

    Figure 7.8. Upload DS Record Step #6

    Upload DS Record Step #6

Finally, let’s verify that the registrar has published the new DS record. This may take anywhere from a few minutes to a few days, depending on your parent zone. You could verify whether or not your parent zone has published the new DS record by querying for the DS record of your zone. In the example below, the Google public DNS server 8.8.8.8 is used:

$ dig @8.8.8.8 example.com. DS

...
;; ANSWER SECTION:
example.com.    21552   IN  DS  24828 7 1 D4A33E8DD550A9567B4C4971A34AD6C4B80A6AD3
example.com.    21552   IN  DS  23550 7 1 54FCF030AA1C79C0088FDEC1BD1C37DAA2E70DFB

You could also query your parent zone’s authoritative name servers directly to see if these records have been published. DS records will not show up on your own authoritative zone, so do not query your own name servers for them. In this recipe, the parent zone is .com, so querying a few of the .com name servers is another appropriate verification.

7.2.2.2. Day of KSK Rollover

If you have followed the examples in this document as described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”, there is technically nothing you need to do manually on the actual day of the rollover. However, you should still keep an eye on the zone to make sure new signature(s) are being generated by the new KSK (23550 in this example). The easiest way is to query the authoritative name server 192.168.1.13 for the same DNSKEY and signatures like you did a month ago:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.   300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAeTJ+w...O+Zy9j0m63
                ) ; KSK; alg = NSEC3RSASHA1; key id = 24828
example.com.   300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150201074900 20150101064900 23550 mydnssecgood.org.
                S6zTbBTfvU...Ib5eXkbtE= )
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150105074900 20141206064900 29747 mydnssecgood.org.
                VY5URQA2/d...OVKr1+KX8= )
...

As you can see, the signature generated by the old KSK (24828) disappeared, replaced by a new signature generated from the new KSK (23550).

7.2.2.3. One Month After KSK Rollover

While the removal of the old DNSKEY from zone should be automated by named, the removal of the DS record is manual. You should make sure the old DNSKEY record is gone from your zone first by querying for the DNSKEY records of the zone, and this time we expect to see one less DNSKEY, namely the key with ID of 24828:

$ dig @192.168.1.13 example.com. DNSKEY +dnssec +multiline

...
;; ANSWER SECTION:
example.com.    300 IN DNSKEY 256 3 7 (
                AwEAAdYqAc...TiSlrma6Ef
                ) ; ZSK; alg = NSEC3RSASHA1; key id = 29747
example.com.    300 IN DNSKEY 257 3 7 (
                AwEAAc1BQN...Wdc0qoH21H
                ) ; KSK; alg = NSEC3RSASHA1; key id = 23550
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150208000000 20150105230000 23550 mydnssecgood.org.
                Qw9Em3dDok...bNCS7KISw= )
example.com.    300 IN RRSIG DNSKEY 7 2 300 (
                20150208000000 20150105230000 29747 mydnssecgood.org.
                OuelpIlpY9...XfsKupQgc= )
...

Now, we can remove the old DS record for key 24828 from our parent zone. Be careful to remove the correct DS record. If we accidentally removed the new DS record(s) of key ID 23550, it could lead to a problem called “security lameness”, as discussed in Section 5.4.1, “Security Lameness”, and may cause users unable to resolve any names in our zone.

  1. After logging in and launched the domain, scroll down to the “DS Records” section and click Manage.

    Figure 7.9. Remove DS Record Step #1

    Remove DS Record Step #1
  2. A dialog appears, displaying both keys (24828 and 23550). Use the far right hand X button to remove the key 24828.

    Figure 7.10. Remove DS Record Step #2

    Remove DS Record Step #2
  3. Key 24828 now appears crossed out, click “Save” to complete the removal.

    Figure 7.11. Remove DS Record Step #3

    Remove DS Record Step #3

Congratulations, the KSK rollover is complete! As for the actual key files (the .key and .private files), they may be deleted at this point, but it’s not required.

7.3. NSEC and NSEC3 Recipes

7.3.1. Migrating from NSEC to NSEC3

This recipe describes how to go from using NSEC to NSEC3, as described in both Section 4.5, “Using NSEC3” and Section 6.2, “Proof of Non-Existence (NSEC and NSEC3) ”. Thie recipe assumes that the zones are already signed, and named is configured according to the steps described in Section 4.1, “Easy Start Guide for Signing Authoritative Zones”.

This command below enables NSEC3 for the zone example.com, using a pseudo-random string 1234567890abcdef for its salt:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

You’ll know it worked if you see the following log messages:

Oct 21 13:47:21 received control channel command 'signing -nsec3param 1 0 10 1234567890abcdef example.com'
Oct 21 13:47:21 zone example.com/IN (signed): zone_addnsec3chain(1,CREATE,10,1234567890ABCDEF)

You can also verify that this worked by querying for a name you know that does not exist, and check for the presence of the NSEC3 record, such as this:

$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline

...
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 1234567890ABCDEF (
                TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
                NS SOA RRSIG DNSKEY NSEC3PARAM )
...

Our example used four parameters: 1, 0, 10, and 1234567890ABCDEF, in the order they appeared. 1 represents the algorithm, 0 represents the opt-out flag, 10 represents the number of iterations, and 1234567890abcedf is the salt. To learn more about each of these parameters, please see Section 6.2.2.1, “NSEC3PARAM”.

For example, to create an NSEC3 chain using the SHA-1 hash algorithm, no opt-out flag, 10 iterations, and a salt value of “FFFF”, use:

# rndc signing -nsec3param 1 0 10 FFFF example.com

To set the opt-out flag, 15 iterations, and no salt, use:

# rndc signing -nsec3param 1 1 15 - example.com

7.3.2. Migrating from NSEC3 to NSEC

This recipe describes how to migrate from NSEC3 to NSEC.

Migrating from NSEC3 back to NSEC is easy, just use the rndc like this:

$ rndc signing -nsec3param none example.com

You know that it worked if you see these messages in log:

named[14093]: received control channel command 'signing -nsec3param none example.com'
named[14093]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)

Of course, you can query for a name that you know that does not exist, and you should no longer see any traces of NSEC3 records.

$ dig @192.168.1.13 reieiergiuhewhiouwe.example.com. A +dnssec +multiline

...
example.com.        300 IN NSEC aaa.example.com. NS SOA RRSIG NSEC DNSKEY
...
ns1.example.com.    300 IN NSEC web.example.com. A RRSIG NSEC
...

7.3.3. Changing NSEC3 Salt Recipe

In Section 6.2.2.3, “NSEC3 Salt”, we’ve discussed the reasons why you may want to change your salt once in a while for better privacy. In this recipe, we will look at what command to execute to actually change the salt, and how to verify that it has been changed.

To change your NSEC3 salt to “fedcba0987654321”, you may run the rndc signing command like this:

# rndc signing -nsec3param 1 1 10 fedcba0987654321 example.com

You should see the following messages in log, assuming your old salt was “1234567890abcdef”:

named[15848]: zone example.com/IN: zone_addnsec3chain(1,REMOVE,10,1234567890ABCDEF)
named[15848]: zone example.com/IN: zone_addnsec3chain(1,CREATE|OPTOUT,10,FEDCBA0987654321)

You can of course, try to query the name server (192.168.1.13 in our example) for a name that does not exist, and check the NSEC3 record returned:

$ dig @192.168.1.13 thereisnowaythisexists.example.com. A +dnssec +multiline

...
TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com. 300 IN NSEC3 1 0 10 FEDCBA0987654321 (
                TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER
                NS SOA RRSIG DNSKEY NSEC3PARAM )
...

Pseudo-Random Salt

You can use a pseudo-random source to create the salt for you. Here is an example on Linux to create a 16-character hex string:

# rndc signing -nsec3param 1 0 10 $(head -c 300 /dev/random | sha1sum | cut -b 1-16) example.com

BIND 9.10 and newer provides the keyword auto which may be used in place of the salt field for named to generate a random salt.

7.3.4. NSEC3 Optout Recipe

This recipe discusses how to enable and disable NSEC3 opt-out, and show the results of each action. As discussed in Section 6.2.2.2, “NSEC3 Opt-Out”, NSEC3 opt-out is a feature that can help conserve resources on parent zones that have many delegations that have yet been signed.

Before starting, for this recipe we will assume the zone example.com has the following 4 entries (for this example, it is not relevant what record types these entries are):

And the zone example.com has 5 delegations to 5 sub domains, only one of which is signed and has a valid DS RRset:

  • aaa.example.com, not signed
  • bbb.example.com, signed
  • ccc.example.com, not signed
  • ddd.example.com, not signed
  • eee.example.com, not signed

Before enabling NSEC3 opt-out, the zone example.com contains ten NSEC3 records, below is the list with plain text name before the actual NSEC3 record:

  • aaa.example.com: 9NE0VJGTRTMJOS171EC3EDL6I6GT4P1Q.example.com.
  • bbb.example.com: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
  • ccc.example.com: SF3J3VR29LDDO3ONT1PM6HAPHV372F37.example.com.
  • ddd.example.com: TQ9QBEGA6CROHEOC8KIH1A2C06IVQ5ER.example.com.
  • eee.example.com: L16L08NEH48IFQIEIPS1HNRMQ523MJ8G.example.com.
  • ftp.example.com: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
  • ns1.example.com: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
  • web.example.com: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
  • http://www.example.com: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
  • example.com: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.

We can enable NSEC3 opt-out with this command, changing the opt-out bit (the second parameter of the 4) from 0 to 1 (see Section 6.2.2.1, “NSEC3PARAM” to review what each parameter is):

# rndc signing -nsec3param 1 1 10 1234567890abcdef example.com

After NSEC3 opt-out is enabled, the number of NSEC3 records is reduced. Notice that the unsigned delegations aaa, ccc, ddd, and eee now don’t have corresponding NSEC3 records.

  • bbb.example.com: AESO0NT3N44OOSDQS3PSL0HACHUE1O0U.example.com.
  • ftp.example.com: JKMAVHL8V7EMCL8JHIEN8KBOAB0MGUK2.example.com.
  • ns1.example.com: FSK5TK9964BNE7BPHN0QMMD68IUDKT8I.example.com.
  • web.example.com: D65CIIG0GTRKQ26Q774DVMRCNHQO6F81.example.com.
  • http://www.example.com: NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ.example.com.
  • example.com: TOM10UQBL336NFAQB3P6MOO53LSVG8UI.example.com.

To undo NSEC3 opt-out, run the same rndc command with the opt-out bit set to 0:

# rndc signing -nsec3param 1 0 10 1234567890abcdef example.com

nsec3hash

NSEC3 hashes the plain text domain name, and we can compute our own hashes using the tool nsec3hash. For example, to compute the hashed name for “www.example.com” using the parameters we listed above, we would execute the command like this:

# nsec3hash 1234567890ABCDEF 1 10 www.example.com.
NTQ0CQEJHM0S17POMCUSLG5IOQQEDTBJ (salt=1234567890ABCDEF, hash=1, iterations=10)

7.4. Reverting to Unsigned Recipe

This recipe describes how to revert from signed zone (DNSSEC) back to unsigned (DNS).

Whether or not the world thinks your zone is signed really comes down to the DS records hosted by your parent zone. If there are no DS records, the world thinks your zone is not signed. So reverting to unsigned is as easy as removing all DS records from the parent zone.

Below is an example of removing using GoDaddy web-based interface to remove all DS records.

  1. After logging in, click the green “Launch” button next to the domain name you want to manage.

    Figure 7.12. Revert to Unsigned Step #1

    Revert to Unsigned Step #1
  2. Scroll down to the “DS Records” section and click Manage.

    Figure 7.13. Revert to Unsigned Step #2

    Revert to Unsigned Step #2
  3. A dialog appears, displaying all current keys. Use the far right hand X button to remove each key.

    Figure 7.14. Revert to Unsigned Step #3

    Revert to Unsigned Step #3
  4. Click Save

    Figure 7.15. Revert to Unsigned Step #4

    Revert to Unsigned Step #4

To be on the safe side, you should wait a while before actually deleting all signed data from your zone, just in case some validating resolvers out there have cached information. After you are certain that all cached information have expired (usually this means TTL has passed), you may reconfigure your zone. This is the named.conf when it is signed, with DNSSEC-related configurations in bold:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    key-directory "keys/example.com";
    inline-signing yes;
    auto-dnssec maintain;
    allow-transfer { any; };
};

Remove the 3 lines so your named.conf looks like this, then use rndc reload to reload the zone:

zone "example.com" IN {
    type master;
    file "db/example.com.db";
    allow-transfer { any; };
};

Your zone is now reverted back to the traditional, insecure DNS format.

7.5. Self-signed Certificate Recipe

This recipe describes how to configure DNS(SEC) to include a TLSA record that acts as a different channel to provide verification for a self-signed x509 (SSL) certificate.

Note

TLSA is still in its infancy. One of the road blocks that exists as of late 2014 is the lack of application support in web browsers and mail applications. As these applications add support for TLSA, steps described in this recipe will become more relevant and practical. Today (as of late 2014), unfortunately, most applications lack native support and will likely result in some kind of error message or warning even if you have deployed TLSA correctly.

Popular applications or servers that provide TLSA support include: Postfix.

For this recipe, we are assuming that you already have a working web server configured with a self-signed x509 certificate. Although the steps described below works for self-signed certificates, it can also be used for “real” certificates that were signed by a Certificate Authority (usually a service you pay for). This is one of several possible uses of DNS-Based Authentication of Named Entities, or DANE (we briefly talked about DANE inSection 6.5.5, “Introduction to DANE”).

First, let’s take a look at the certificate used by you web server:

# cat server.crt
-----BEGIN CERTIFICATE-----
MIICVTCCAb4CCQChk/gPoAqkWjANBgkqhkiG9w0BAQsFADBvMQswCQYDVQQGEwJV
UzELMAkGA1UECAwCQ0ExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xITAfBgNVBAoM
GEludGVybmV0IFdpZGdpdHMgUHR5IEx0ZDEYMBYGA1UEAwwPd3d3LmV4YW1wbGUu
Y29tMB4XDTE0MTIwODA2MDMxNFoXDTI0MTIwNTA2MDMxNFowbzELMAkGA1UEBhMC
VVMxCzAJBgNVBAgMAkNBMRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMSEwHwYDVQQK
DBhJbnRlcm5ldCBXaWRnaXRzIFB0eSBMdGQxGDAWBgNVBAMMD3d3dy5leGFtcGxl
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzovVMAexPZHg8MaL2xfE
IfwPKxCdcCzF2eEvl3euIk2esQ0r3GE+xEVqf/lggCC0OH0q6TXs+6XFYvc4+O/m
LEh6DFnfn8Kz3T0d6mG2l8YuhhkLLrwugvvaAcHqMoVeZRPqFLhlfaUsoGxb+CPs
3B8xYFisUqNJp6Tr26MhSVECAwEAATANBgkqhkiG9w0BAQsFAAOBgQC7lQbdSkaM
x8B6RIs+PMOZ14RlA1UcPNUPPAK0vK23/ie1SfxSHIw6PlOba+ZQZusrDRYooR3B
viM+cUnhD5UvhU4bn3ZP0cp+WNsimycf/gdfkAe47Em1oVNZP6abUgqMPStongIB
7uonP6j74A/BTF5kdUsaDPoDfvGnCjZMsQ==
-----END CERTIFICATE-----

Next, use openssl to generate a SHA-256 fingerprint of this certificate, this is what you will list in DNS as a TLSA record. Also, you need to remove all the colons, hence the added sed at the end to filter out all “:” characters:

# openssl x509 -noout -fingerprint -sha256 < server.crt | tr -d :
SHA256 Fingerprint=294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F50C4A3BB

Now you can insert the TLSA record by editing the zone file the old fashioned way, or if your DNS server is allowing dynamic updates, you could use nsupdate like this to inject the TLSA record:

# nsupdate
> server localhost
> update add _443._tcp.www.example.com. 3600 IN TLSA 3 0 1 294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F50C4A3BB
> send
> quit

Let’s talks briefly about the record you just added. The name is a specifically formed “_443._tcp.www.example.com”, which specifies the usage of TCP port 443, for the name “www.example.com”. It is followed by three parameters, each representing usage, selector, and matching type. For this recipe, we will not dissect into all the possible combinations of these parameters. The examples listed here are 3, 0, and 1, which represent:

  • Usage: 3 = self-signed certificate
  • Selector 0 = full certificate is included
  • Matching Type 1 = SHA-256

If you are interested in learning (a lot) more about the TLSA record type, check out “A Step-by-Step guide for implementing DANE with a Proof of Concept” by Sandoche Balakrichenan, Stephane Bortzmeyer, and Mohsen Souissi (April 15, 2013)

Assuming you have successfully added the new TLSA record and generated the appropriate signature(s), now you can query for it:

$ dig _443._tcp.www.example.com. TLSA

...
;; ANSWER SECTION:
_443._tcp.www.example.com.  3600 IN TLSA    3 0 1 294874DA378148CDD1B9C57D2E891E8C294D2958F0BCA7400A0D6D6F 50C4A3BB
...

Great! But that’s still only half of the equation. We still need to make your web browser utilize this new information. For this recipe, we are showing you results of using Firefox with a plugin called DNSSEC TLSA Validator fromhttps://www.dnssec-validator.cz.

Once the plugin is installed, activated, and Firefox restarted, when you visit the URL https://www.example.com, your browser will prompt you for a warning, because this is a self-signed certificate:

Figure 7.16. Browser Certificate Warning

Browser Certificate Warning


Although the certificate is not trusted by the browser itself (if you want to you’ll have to install a custom CA root or make the browser trust the certificate individually), the plugin shows that it was able to verify the information it received via HTTPS (port 443), and that it matches the information it received via TLSA lookup over DNS (port 53).

Figure 7.17. DNSSEC TLSA Validator

DNSSEC TLSA Validator

Chapter 8. Commonly Asked Questions

No questions are too stupid to ask, below is a collection of such questions and answers.

Q: Do I need IPv6 to have DNSSEC?
Q: Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?
Q: Does DNSSEC protect the communication between my laptop and my name server?
Q: Does DNSSEC secure zone transfers?
Q: Is DNSSEC going to protect me from malicious web sites?
Q: If I enable DNSSEC validation, will it break DNS lookup for majority of the domain names, since most domains names don’t have DNSSEC yet?
Q: Do I need to have special client software to use DNSSEC?
Q: Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?
Q: Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?
Q: My parent zone does not support DNSSEC, can I still sign my zone?
Q: Is DNSSEC the same thing as TSIG that I have between my master and slave servers?
Q: How are keys copied from master to slave server(s)?
Q: Do I need IPv6 to have DNSSEC?
A: No. DNSSEC can be deployed independent of IPv6.
Q: Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?
A: No. Although cryptographic keys and digital signatures are used in DNSSEC, they only provide authenticity and integrity, not privacy. Someone who sniffs network traffic can still see all the DNS queries and answers in plain text, DNSSEC just makes it very difficult for the eavesdropper to alter or spoof the DNS responses.
Q: Does DNSSEC protect the communication between my laptop and my name server?
A: Unfortunately, currently, no. DNSSEC is designed to protect the communication between the end clients (laptop) and the name servers, however, there are few applications or stub resolver libraries as of late 2014 that take advantage of this capability. This communication between the recursive server to the clients are commonly called the “last mile”, while enabling DNSSEC today does little to enhance the security for the last mile, we hope that will change in the near future as more and more applications become DNSSEC-aware.
Q: Does DNSSEC secure zone transfers?
A: No. You should consider using TSIG to secure zone transfers among your name servers.
Q: Is DNSSEC going to protect me from malicious web sites?
A: The answer for now is, unfortunately for early stages of DNSSEC deployment, no. DNSSEC is designed so you can have confidence that when you received the DNS response for http://www.isc.org over port 53, you know it really came from the ISC name servers, and the answers are authentic. But that does not mean the web server you visit over port 80 or port 443 is necessarily safe. Further more, 99% of the domain names (as of this writing) have not signed their zones yet, so DNSSEC cannot even validate their answers.

The answer for sometime in the future is, as more and more zones are signed and more and more recursive servers are validating, DNSSEC will make it much more difficult for attackers to spoof DNS responses or perform cache poisoning. It still does not protect users from visiting a malicious web site that the attacker owns and operates, or prevent users from mis-typing a domain name, it just becomes unlikely that the attacker can hijack other domain names.

Q: If I enable DNSSEC validation, will it break DNS lookup for majority of the domain names, since most domains names don’t have DNSSEC yet?
A: No, DNSSEC is backwards compatible to “standard” DNS. As of this writing, although 99% of the .com domains have yet to be signed, a DNSSEC-enabled validating resolver can still lookup all of these domain names following the “old fashioned way”. There are four (4) categories of responses (RFC 4035 Sec 4.3):

  1. Secure: Domains that have DNSSEC deployed correctly
  2. Insecure: Domains that have yet to deploy DNSSEC
  3. Bogus: Domains that deployed DNSSEC but did it incorrectly
  4. Indeterminate: Unable to determine whether or not to use DNSSEC

A validating resolver will still resolve #1 and #2, only #3 and #4 will result in a SERVFAIL.You may already be using DNSSEC validation without realizing it, since some ISP’s have begun enabling DNSSEC validation on their recursive name servers. Google public DNS (8.8.8.8) also has enabled DNSSEC validation.

Q: Do I need to have special client software to use DNSSEC?
A: The short answer is no, DNSSEC only changes the communication behavior among DNS servers, not DNS server (validating resolver) and client (stub resolver). With DNSSEC validation enabled on your recursive server, if a domain name doesn’t pass the checks, an error message (typically SERVFAIL) is returned to the clients, and to most client software today, it looks as if the DNS query has failed, or the domain name does not exist.

The longer answer is although you don’t have to, you may want to. There are more and more client softwares that take advantage of the new DNSSEC features and give user better feedback about the domain name they are visiting. CZ.NIC Lab’s has created a plugin for several popular web browsers, and Mozilla has created a new web browser Bloodhound that performs DNSSEC validation.

As DNSSEC deployment becomes more common place, we are sure to see more and more software libraries and applications be updated to support its features.

Q: Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?
A: No.
Q: Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?
A: No. With DNSSEC, you generate and publish your own keys, and sign your own data as well. There is no need to pay someone else to do it for you.
Q: My parent zone does not support DNSSEC, can I still sign my zone?
A: Technically, yes, you can sign your zone, but you wouldn’t be getting the full benefit of DNSSEC, as other validating resolvers would not be able to validate your zone data. Without the DS record(s) in your parent zone, other validating resolvers will treat your zone as an insecure (traditional) zone, thus no actual verification is carried out. The end result is, to the rest of the world, your zone still appears to be insecure, and it will continue to be insecure until your parent zone can host DS record(s) for you, effectively telling the rest of the world that your zone is signed.

An interim solution is to take advantage of DLV (DNSSEC Look-aside Validation), by submitting your key to a DLV registry such as https://dlv.isc.org/, you can still get the benefits of DNSSEC even if your parent zone is not yet supporting it.

Q: Is DNSSEC the same thing as TSIG that I have between my master and slave servers?
A: No. TSIG is typically used between master and slave name servers to secure zone transfers, DNSSEC secures DNS lookup by validating answers. Even if you enabled DNSSEC, zone transfers are still not validated, and if you wish to secure the communication between your master and slave name servers, you should consider setting up TSIG or similar secure channels.
Q: How are keys copied from master to slave server(s)?
A: DNSSEC uses public cryptography, which results in two types of keys: public and private. The public keys are part of the zone data, stored as DNSKEY record types. Thus the public keys are synchronized from master to slave server(s) as part of the zone transfer. The private keys do not, and should not be stored anywhere else but the master server in a secured fashion. See Section 6.3, “Key Storage” for more information on key storage options and considerations.

Guide from: http://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html

SSL-DNS


Intro

Inspired by the HTTPS-DNS project I started to look for another approach for doing encrypted dns-requests. The following solution should work with nearly all unixoid operatingsystems ( for Microsoft Windows see below ) and can easily be applied. It works absolutly transparently for the clients and servers.

Encrypting DNS-requests is usefull, because it

  • prevents manipulation of dns-requests
  • prevents recognizing of dns-requests
  • prevents logging of dns-requests

Implementation

The whole concept is based on socat for udp <-> tcp and stunnel for TLS-encryption between the clients and the dns-server.

On the serverside we have a normal dns-server running like bind, which is reachable on port 53. Now we use stunnel to create a new TLS-server on port 5667. stunnel forwards the packets on the localhost to socat, which forwards them to bind. You have to use socat because dns requests use udp but stunnel just supports tcp. But with socat we can forward udp to tcp, back and forth again.

On the clientside we configure socat to forward udp packets from port 53 to stunnel as tcp and stunnel to forward them to the server on port 5667. We then configure ure client to use the localhost as dns server.

Client

If you want your client machine to make dns-requests over SSL you have to install socat and stunnel .

Modify your /etc/stunnel/stunnel.conf to this:

sslVersion = SSLv3

chroot = /var/run/stunnel
setuid = stunnel
setgid = stunnel
pid = /stunnel.pid

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:1
socket = r:SO_LINGER=1:1

client = yes
verify=0

[dns]
accept  = 5666
connect = IPOFDNSSERVER:TLS-DNS-PORT #          !!!!!!!!!!!!!!!!modify this!!!!!!!!!!!!!!
TIMEOUTidle = 1
TIMEOUTclose = 1
TIMEOUTbusy = 1

and start the stunnel-daemon. Now start socat:

 $socat udp4-listen:53,reuseaddr,fork tcp:localhost:5666

That’s it! Test it with:

 dig @localhost www.google.de

Now all you have to do is make your system use the localhost as dns server. This is very distributionspecific, so look at the doc of your distro. To permanently use TLS-DNS, make stunnel and socat start at boot.

Running Servers

The following servers offers SSL-DNS:

  1. 62.141.58.13 Port: 5353
  2. 88.84.155.209 Port: 5667

Setup a Server

If you are running a dns server and want to extend it to support SSL-DNS you can do this pretty easy. This won’t conflict with your existing dns-server in any way. It has been tested on debian lenny with bind9. I expect in the following that you correctly installed your dns server and it is reachable by port 53.

For the stunnel-server you have to create a key:

  •  $openssl req -new -x509 -days 3650 -nodes -out dns.pem -keyout dns.pem

, move it to /etc/stunnel/ and change its permissions to 600. Now configure your stunnel.conf like this:

cert = /etc/stunnel/dns.pem

sslVersion = SSLv3

chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
pid = /stunnel4.pid

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:1
socket = r:SO_LINGER=1:1

[dns]
accept  = 5667
connect = localhost:53

Start stunnel and your SSL-DNS server is up and running. You do not need socat at the server, because bind9 is able to handle TCP requests.

Your server offers now:

DNS - port 53
TLS-DNS - port 5667

Windows

You need to use socat windows-port and stunnel for Windows.

Modify your stunnel.conf (Start -> Programs -> stunnel -> Edit Stunnel.conf) to this:

sslVersion = SSLv3

socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
socket = l:SO_LINGER=1:1
socket = r:SO_LINGER=1:1

client = yes
verify=0

[dns]
accept  = 5666
connect = IPOFDNSSERVER:TLS-DNS-PORT #       For example 88.84.155.209:5667
TIMEOUTidle = 1
TIMEOUTclose = 1
TIMEOUTbusy = 1

and start the stunnel-daemon (run stunnel). Now start socat:

 $socat udp4-listen:53,reuseaddr,fork tcp:localhost:5666

Now you need to go to your control panel and edit the network configuration. Put 127.0.0.1 as your favourite DNS server. Make sure its working, check it by opening some websites and then closing stunnel. With stunnel closed you shouldn’t be able to continue browsing.

Portable OpenSSH


See http://www.openssh.com/txt/release-6.8 for the release notes.

- A Japanese translation of this document and of the OpenSSH FAQ is
- available at http://www.unixuser.org/~haruyama/security/openssh/index.html
- Thanks to HARUYAMA Seigo <haruyama@unixuser.org>

This is the port of OpenBSD's excellent OpenSSH[0] to Linux and other
Unices.

OpenSSH is based on the last free version of Tatu Ylonen's sample
implementation with all patent-encumbered algorithms removed (to
external libraries), all known security bugs fixed, new features
reintroduced and many other clean-ups.  OpenSSH has been created by
Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt,
and Dug Song. It has a homepage at http://www.openssh.com/

This port consists of the re-introduction of autoconf support, PAM
support, EGD[1]/PRNGD[2] support and replacements for OpenBSD library
functions that are (regrettably) absent from other unices. This port
has been best tested on AIX, Cygwin, HP-UX, Linux, MacOS/X,
NetBSD, OpenBSD, OpenServer, Solaris, Unicos, and UnixWare.

This version actively tracks changes in the OpenBSD CVS repository.

The PAM support is now more functional than the popular packages of
commercial ssh-1.2.x. It checks "account" and "session" modules for
all logins, not just when using password authentication.

OpenSSH depends on Zlib[3], OpenSSL[4] and optionally PAM[5].

There is now several mailing lists for this port of OpenSSH. Please
refer to http://www.openssh.com/list.html for details on how to join.

Please send bug reports and patches to the mailing list
openssh-unix-dev@mindrot.org. The list is open to posting by
unsubscribed users.Code contribution are welcomed, but please follow the 
OpenBSD style guidelines[6].

Please refer to the INSTALL document for information on how to install
OpenSSH on your system. There are a number of differences between this
port of OpenSSH and F-Secure SSH 1.x, please refer to the OpenSSH FAQ[7]
for details and general tips.

Damien Miller <djm@mindrot.org>

Miscellania -

This version of OpenSSH is based upon code retrieved from the OpenBSD
CVS repository which in turn was based on the last free sample
implementation released by Tatu Ylonen.

References -

[0] http://www.openssh.com/faq.html
[1] http://www.lothar.com/tech/crypto/
[2] http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
[3] http://www.gzip.org/zlib/
[4] http://www.openssl.org/
[5] http://www.openpam.org
    http://www.kernel.org/pub/linux/libs/pam/ 
    (PAM also is standard on Solaris and HP-UX 11)
[6] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9
[7] http://www.openssh.com/faq.html

$Id: README,v 1.87 2014/08/10 01:35:06 djm Exp $

More information can be found on:https://github.com/openssh/openssh-portable

OpenVPN Netfilter – Per VPN user network ACLs using Netfilter


openvpn-netfilter

Per VPN user network ACLs using Netfilter and OpenVPN.

Setup

While the script is fast, it still hangs OpenVPN for a second while running, which may be felt by VPN users. To minimize the impact the script blocks all connections then fork off and return control to openvpn. The fork finishes the rule setup.

learn-address /usr/lib/openvpn/plugins/netfilter_openvpn.sh

If using LDAP for user authentication, add this to the OpenVPN server configuration:

username-as-common-name

For any OpenVPN server configuration, also add this (or a sudo wrapper to this script, if needed. You may also use capabilities.):

#This is necessary so that openvpn delete the ip after 20s, assuming the client has gone away
#This may not be needed for TCP VPNs since the VPN knows when the client has gone away. (have not tested)
#For the same reason, remember to kill a client for at least 20s, or SIGUSR1 openvpn if you're changing ACLs for that client.
keepalive 10 20

Change the settings in /etc/openvpn/netfilter_openvpn.conf.

In general, you’ll want to store the rules in /etc/openvpn/netfilter/rules/* and have a list of files such as “vpn_teamA.rules”. Users belonging to the LDAP group name teamA will get those rules. You’ll also want to have /etc/openvpn/netfilter/users/* for per user rules. Likewise, make sure that the paths of the ‘iptables’, ‘ipset’, and ‘vpn-netfilter-cleanup-ip.sh’ commands are correct for your system.

Don’t forget to push the proper routing rules for the network/IPs you allow.

Rule format

Rules are formatted as list of ips or networks (anything netfilter understands for an address or network really), such as:

# Lines starting with a # sign can be used for comments
127.0.0.1
127.0.0.1/27
# Obviously you might want to use slightly more useful rules ;-)

Script logic

learn-address is an OpenVPN hook called when the remote client is being set an IP address at the VPN server side. It calls the netfilter script, which in turn will load the netfilter (iptables) rules for that IP address, per given cn name (cn name is the username in the certificate, or the LDAP user name).

If the script fails for any reason, OpenVPN will deny packets to come through.

When a user successfully connects to OpenVPN, netfilter.py will create a set for firewall rules for this user. The custom rules are added into a new chain named after the VPN IP of the user:

Chain 172.16.248.50 (3 references)
 pkts bytes target     prot opt in     out     source               destination
 5925  854K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           ctstate ESTABLISHED /* ulfr at 172.16.248.50 */
  688 46972 ACCEPT     all  --  *      *       172.16.248.50        0.0.0.0/0           match-set 172.16.248.50 dst /* ulfr groups: vpn_caribou;vpn_pokemon;vpn_ninjas;*/
   24  2016 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* ulfr at 172.16.248.50 */ LOG flags 0 level 4 prefix `DROP 172.16.248.50'
   24  2016 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           /* ulfr at 172.16.248.50 */

A jump target is added to INPUT, OUTPUT and FORWARD to send all traffic originating from the VPN IP to the custom chain:

Chain INPUT (policy ACCEPT 92762 packets, 15M bytes)
 3320  264K 172.16.248.50  all  --  *      *       172.16.248.50         0.0.0.0/0
Chain OUTPUT (policy ACCEPT 136K packets, 138M bytes)
 2196  549K 172.16.248.50  all  --  *      *       0.0.0.0/0            172.16.248.50
Chain FORWARD (policy ACCEPT 126K packets, 127M bytes)
 1120 90205 172.16.248.50  all  --  *      *       172.16.248.50         0.0.0.0/0

You’ll notice the comments are there for ease of troubleshooting, you can grep through “iptables -L -n” and find out which user or group has access to what easily.

To reduce the amount of rules created, when the LDAP ACLs only contains a list of destination subnets, these subnets are added into an IPSet. The IPSet is named after the VPN IP of the user.

--- IPSET HASH TABLE ---
Name: 172.16.248.50
Type: hash:net
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 17968
References: 1
Members:
172.39.72.0/24
172.31.0.0/16
172.11.92.150
42.89.217.202

Maintenance

You can list the rules and sets of a particular user with the script named ‘vpn-fw-find-user.sh’.

You can delete all of the rules and sets of a given VPN IP using the script named ‘vpn-netfilter-cleanup-ip.sh’.

Upgrading

On rule upgrades, start the script ‘vpn-netfilter-cleanup-ip.sh’ within ‘netfilter_openvpn.sh’ until all rules are upgraded. You may also do this all the time but this has a performance cost associated.


More information can be found on: https://github.com/gdestuynder/openvpn-netfilter

Pragmatic-SSL-TLS – Slides from talk: SSL-TLS Infrastructure at Mozilla


Slides from my talk “SSL-TLS Infrastructure at Mozilla”

Grab them from: https://github.com/jvehent/pragmatic-ssl-tls

Chef KeyMaster – distribute encryption keys across the nodes of an environment using Chef


KeyMaster – Encrypted DataBag Key Distribution Service

This cookbook configures a service that will distribute encryption keys across the environment. Encrypted databags are immensely useful, but Chef doesn’t provide a mechanism for managing the keys. Each encrypted databag requires a symetric key. Using only one symetric key for the entire system defeats the purpose of encryption.

The Keymaster cookbooks provides a method for distributing keys on nodes. It requires only one Master Key that is manually copied to the keymaster server, and will be used to distribute all other encryption keys used in encrypted databags.

Attributes

Path to the Master key on the keymaster server. Keep this secure

default[:keymaster][:storage][:master_key] = '/etc/keymaster/keymaster.key'

Directory where all the distributed keys will be stored

default[:keymaster][:storage][:path] = '/etc/keymaster/keys/'

Name of the data bag that contains the keys to be distributed

default[:keymaster][:key_bag_name] = 'keymaster'

How often to we redistribute the key on a destination node, in minutes.

default[:keymaster][:distribute][:every] = 420

Name of the keymaster system user that will be SSHing onto the destination nodes.

default[:keymaster][:user] = 'keymaster'

Enable the keymaster client recipe, should be set to false on the keymaster server.

default[:keymaster][:client][:enable] = true

Distribution History

When keys are distributed, a history of the distribution is kept. It’s a simple key value hash, where the key is an identifier of the destination and the distributed key, and the value is the time of last distribution.

Principle

Client side

Each client must run the recipe keymaster::client in order to create a keymaster user locally, and put the public SSH key of the keymaster server into /home/keymaster/.ssh/authorized_keys. This keymaster server cookbook will connect to the keymaster user on each destination node, and distribute the keys using SCP.

Mode of operations


    xxxxxxx
   x -    -x                                        +-----------------------+
   x   --  x                                        |                       |
   x \____/x                                        |   CHEF                |
    xxxxxxx                                         |                       |
       x        +-------------+                     |                       |
      xxx       |enc. databag +--------------------->        SERVER         |
     x x x      |  +---+      |         (2)         |                       |
    x  x  x     |  |key|      |                     |                       |
      xxx       +--+---+------+                     |                       |
     x   x   +-----------+         __________________                       |
    x     x  |+---------+|        /                 |                       |
 security    ||MasterKey||       /                  +-----------------------+
 focused     |+---------+|      /
 invididual  +---+-------+     /
                 |            / (3)
                 |(1)        /
                 |          /
   +-------------v---+     /
   |                 <-----                              +-------------------+
   |  KEYMASTER      |                     (4)           | DESTINATION       |
   |        SERVER   +---------------------------------->|            NODE   |
   +-----------------+                                   +-------------------+

Say that you need an encrypted databagXYZ for service123. You create a secret secretXYZ and encrypt databagXYZ with it. Now you want secretXYZ to be copied over the nodes A, B and C so that they can decrypt databagXYZ.

The KeyMaster cookbook does this for you.

  1. Create a Master Key (preferably one per environment) openssl rand -base64 2048 | tr -d '\r\n' > ~/.chef/keymaster.key Copy the key manually to the Keymaster server scp ~/.chef/keymaster.key /etc/keymaster/keymaster.key
  2. Using Knife, create a Keymaster encrypted databag for secretXYZ in the keymaster databag, using keymaster.key knife data bag create --secret-file ~/.chef/keymaster.key keymaster secretXYZ The databag must contain a destination (chef search that returns the nodes that need secretXYZ), and a key (secretXYZ).
id:           service123-databagXYZ-production
destination:  tags:service123 AND roles:python-api-node AND chef_environment:production
key:          kDXL84t+6LRm0Kbqqhef72......

The encrypted version will look as follow:

destination:  6p4obWgLtbFOWRvfNMN1RwtroTwx/9hB88xsgM5fnP6j1rMeJ/OL2Sgm8ulQ
              3DfMn5b8E7PCoYuEa99u7Plox+JyAUHK/TiE2TGhTt16bQxQFL+ZN4YK+bv8
              TxNZpxhgB43R+7qG+HVYAgmPu9Sr/g==
id:           service123-databagXYZ-production
key:          wKEx1zGdDQfsyterl/2mLLZ68ZNsjks3ZAEo2bIDux0Ux6fh3UDztoNt2NJ1
              xk8bhSkLtQkSNTXBPYWGGDElo1Ttx9xZC1KLUPEW2EzWy4Vb3m/UI+ly53Z9
              3I4RMXDVl+RQl8pWMIig9SbeneUY+C8iojLkx71qmD5ksxrjehgsZPpNct3s
              zmS5Wlxzl7HG6AYs4t084su+Yj0sRG4kkmzh0AKCjLu5nyElRtpcm63G9G5o
              r7114Prrkqj6giDiIHmuPZE7g3cACtJwGOYTJ4yKKu2XvCs7QyYOYYP++ycS
              iMvp4fMv3XN+quWd4wCy/zpjssmLr+YveZzk5E6acCkPdu4Fkumb8JZKgtic
              +OlTNKsA8E8r7i9yDesNi1Xnq5/Kro
  1. During provisioning, the Keymaster will retrieve the encrypted databag from chef-server, decrypt the keys and store them locally.
  2. The destination of each key is resolved, and keymaster uses scp to send the keys over to the destination nodes. ## Keymaster server directories organization Inside the keymaster, all keys are stored in the directory defined in default[:keymaster][:storage][:path] (default to /etc/keymaster/keys/). The cookbooks stored the keys unencrypted and uses SSH to copy them over to the destination nodes. The Master Key must be stored at the location of default[:keymaster][:storage][:master_key](defaults to /etc/keymaster/keymaster.key). It is stored unencrypted.

Key re-distribution

The Keymaster does not have a reliable way to determine if a key has changed on the destination node. Therefore, keys are overwritten on a regular basis (defaults to 420 minutes – 7 hours – and defined by default[:keymaster][:distribute][:every]).

The keymaster keeps history of when a key was distributed to a node, this history is kept in a node attribute node[:keymaster][:history]. Node names are hashes to prevent information leakage from the history.

Data Bag Items Decryption

Keymaster is stricly a key distribution service. It does not care for what you encrypt using the keys it distributes. Nevertheless, Keymaster provides a function that can be used in recipes of other cookbook to decrypt data bag items.

A cookbook that depends "keymaster" can use the following code to decrypt an encrypted databag:

  key_location = "#{node['keymaster']['storage']['path']}/cookbooksecure.key"
  dbag_item = {}
  begin
    dbag_item = Keymaster.decrypt_data_bag_item("mydatabag",
                                                "myitem",
                                                key_location)
  rescue IOError
    Chef::Log.info("Decryption failed. Moving on.")
    return true
  end

The variable dbag_item will receive a hash with the decrypted values, that can be used in a template or anywhere else in the recipe.

Note: The cookbook must have depends "keymaster" in its metadata.rb in order to have access to thisKeymaster module function.

Note: If the begin/rescue block catches an IOError exception, the processing of the entire recipe willNOT fail. Only the resources listed after the begin/rescue block will be skipped. To make the recipe truly atomic and prevent a recipe from being partially deployed, either put the begin/rescue block at the top of your recipe, or put all of the resources in the ‘begin’ portion of the block.

Vagrant

The vagrant VMs come with a master key by default, such that the keymaster VM can be provisionned without having to recreate a key. The key is:

+Vrfxe35zyoqYFon7DrMEiudouoJutm8lNoOHSHXsTVCgjcALmwCXkVgR0vyJ+h4mPI0l3wCUC7aiTxcJsPWlSIvvLhcmJv2YVyjnerDZ0Z/y9rdab2yYJLV+gE1LnSZD4LHk/0AsF5nOCZVXwdjFDxq70TZUJcm19t27OUlvPwf3cG9LoAaH5p0SRvomkNCAqRNrn0323pj8vTicTtbosPDEVapuXh8pJwWedSu8Em4/qyG6TJzU3XMB/Q993UBwzNYnzzmGMJj+PuF91bLWqj/HF6rctHvyNex/ASew5chsAebCRDG8f7G8hv7x3n2phDzKyRK8w1/hXywh85IUDLdI/sNlJy1ZR1iOHC/RaUa8MUL1trLlD8TA4JW1ifPKnp4zMSIf880r8Po6kCnxlD8WLCxx1sVK92BtSuysr9qYPJU5ghzDv6+O6mNqUDY+MoSiryiAW7oDKWmQOKM2CekmSO9/VuYTzgbOxY+bfscQIUvONJX46n/4OH80OVcayjcf6C6FjMBEhD7owfA6BbrXSju08IcdH6KTAH4FEGjexXpSTHhf7QAUh77x6CES55CLMvWw17spI+W1lgc/NC2czAPoOtTg+wxWSzNzwPBfdD3jVaZCH+qyfYtkONkaqCvMVbLrUmBmLLNNJodBgQQf99cQYtmr18mU1MWaCM=




More information can be found on: https://github.com/jvehent/chef-keymaster

Onion Pi – Build a Raspberry Pi Tor Onion Router Machine


Onion Pi

Another Excellent Raspberry Pi project which is now coming bundled with Tor Onion Router which gives you opportunity to create secure network wherever you are. For more information about the project please visit Adafruit Learning System. Credit: Created by Ladyada [ Many Many TNX ] As usually discussion is open on ARRAKIS  

Feel like someone is snooping on you? Browse anonymously anywhere you go with the Onion Pi Tor proxy. This is fun weekend project that uses a Raspberry Pi, a USB WiFi adapter and Ethernet cable to create a small, low-power and portable privacy Pi.

Using it is easy-as-pie. First, plug the Ethernet cable into any Internet provider in your home, work, hotel or conference/event. Next, power up the Pi with the micro USB cable to your laptop or to the wall adapter. The Pi will boot up and create a new secure wireless access point called Onion Pi. Connecting to that access point will automatically route any web browsing from your computer through the anonymizing Tor network.

What is Tor?

Tor is an onion routing service – every internet packet goes through 3 layers of relays before going to your destination. This makes it much harder for the server you are accessing (or anyone snooping on your Internet use) to figure out who you are and where you are coming from. It is an excellent way to allow people who are blocked from accessing websites to get around those restritions.

According to the Tor website:

Journalists use Tor Onion to communicate more safely with whistleblowers and dissidents. Non-governmental organizations (NGOs) use Tor to allow their workers to connect to their home website while they’re in a foreign country, without notifying everybody nearby that they’re working with that organization.Groups such as Indymedia recommend Tor Onion for safeguarding their members’ online privacy and security. Activist groups like the Electronic Frontier Foundation (EFF) recommend Tor as a mechanism for maintaining civil liberties online. Corporations use Tor as a safe way to conduct competitive analysis, and to protect sensitive procurement patterns from eavesdroppers. They also use it to replace traditional VPNs, which reveal the exact amount and timing of communication. Which locations have employees working late? Which locations have employees consulting job-hunting websites? Which research divisions are communicating with the company’s patent lawyers?A branch of the U.S. Navy uses Tor for open source intelligence gathering, and one of its teams used Tor while deployed in the Middle East recently. Law enforcement uses Tor for visiting or surveilling web sites without leaving government IP addresses in their web logs, and for security during sting operations.

BEFORE YOU START USING YOUR PROXY – remember that there are a lot of ways to identify you, even if your IP address is ‘randomized’. Delete & block your browser cache, history and cookies – some browsers allow “anonymous sessions”. Do not log into existing accounts with personally identifying information (unless you’re sure that’s what you want to do). And read https://www.torproject.org/ for a lot more information on how to use TOR in a smart and safe way
This tutorial is a great way to make something fun and useful with your Raspberry Pi, but it is a work in progress. We can’t guarantee that it is 100% anonymous and secure! Be smart & paranoid about your TOR usage.

What you’ll need

You’ll need a few things to run this tutorial:

Chances are you’ve got a couple of these items already. If not, our Onion Pi starter pack has everything you need !

Preparation

This tutorial assumes you have your Pi mostly set up and have followed our “Raspberry Pi as Wifi Access Point” tutorial

Please follow these tutorials in order to

Make sure to expand the filesystem to the entire disk or you may run out of space

Onion

When done you should have a Pi that is booting Raspbian, you can connect to with a USB console cable and log into the Pi via the command line interface.

When done you should be able to connect to the Pi as a WiFi access point and connect to the internet through it.

It is possible to do this tutorial via ssh on the Ethernet port or using a console cable.

If using a console cable, even though the diagram on the last step shows powering the Pi via the USB console cable (red wire) we suggest not connecting the red wire and instead powering from the wall adapter. Keep the black, white and green cables connected as is.

Install TOR

Essentially, this tutorial just follows the tor “anonymizing middlebox” writeup here.

We’ll begin by installing tor – the onion routing software.

Log into your pi by Ethernet or console cable and run

sudo apt-get install tor
5

Edit the tor config file by running

sudo nano /etc/tor/torrc

and copy and paste the text into the top of the file, right below the the FAQ notice.

Copy Code
Log notice file /var/log/tor/notices.log
VirtualAddrNetwork 10.192.0.0/10
AutomapHostsSuffixes .onion,.exit
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 192.168.42.1
DNSPort 53
DNSListenAddress 192.168.42.1
6
Let’s edit the host access point so it is called something memorable like Onion Pi – don’t forget to set a good password, don’t use the default here!
Time to change our ip routing tables so that connections via the wifi interface (wlan0) will be routed through the tor software.
Type the following to flush the old rules from the ip NAT table

sudo iptables -F
 sudo iptables -t nat -F

Type the following to route all DNS (UDP port 53) from interface wlan0 to internal port 53 (DNSPort in our torrc)

sudo iptables -t nat -A PREROUTING -i wlan0 -p udp --dport 53 -j REDIRECT --to-ports 53

Type the following to route all TCP traffic from interface wlan0 to port 9040 (TransPort in our torrc)

8

sudo iptables -t nat -A PREROUTING -i wlan0 -p tcp --syn -j REDIRECT --to-ports 9040

Next you can check that the ip tables are right with

sudo iptables -t nat -L
9

If all is good, we’ll save it to our old NAT save file

sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"

It will automatically get loaded when the networking is set up on reboot (as we did in the last tutorial on making a Pi access point)

10

Next we’ll create our log file (handy for debugging) with

sudo touch /var/log/tor/notices.log
sudo chown debian-tor /var/log/tor/notices.log
sudo chmod 644 /var/log/tor/notices.log

Check it with

ls -l /var/log/tor

Start the tor service manually

sudo service tor start

Check its really running (you can run this whenever you’re not sure, it something is wrong you’ll see a big FAIL notice

sudo service tor status

Finally, make it start on boot

sudo update-rc.d tor enable
11
That’s it, now you’re ready to test in the next step.

Test It!

OK now the fun part! It’s time to test your TOR anonymizing proxy. On a computer, check out the available wifi networks, you should see the Onion Pi network
12
Connect to it using the password you entered into the hostapd configuration file
13
You can open up a Terminal or command prompt and ping 192.168.42.1 to check that your connect to the Pi is working. However you won’t be able to ping outside of it because ping’s are not translated through the proxy
13
To check that the proxy is working, visit a website like http://www.ipchicken.com which will display your IP address as it sees it and also the matching domain name if available. The IP address should not be from your internet provider – in fact, if you reload the page it should change!
14
Your web browsing traffic is now anonymized!

onion onion onion onion onion

BEFORE YOU START USING YOUR PROXY – remember that there are a lot of ways to identify you, even if your IP address is ‘randomized’. Delete your browser cache, history and cookies (some browsers allow “anonymous sessions”) and read https://www.torproject.org/ for a lot more information on how to use Tor Onion Rrouter in a smart and safe way

Simple Overview of OpenVPN


OpenVPN: Simple Overview

If you want more than just pre-shared keys OpenVPN makes it easy to setup and use a Public Key Infrastructure (PKI) to use SSL/TLS certificates for authentication and key exchange between the VPN server and clients. Open VPN can be used in a routed or bridged VPN mode and can be configured to use either UDP or TCP. The port number can be configured as well, but port 1194 is the official one. And it is only using that single port for all communication. VPN client implementations are available for almost anything including all Linux distributions, OS X, Windows and OpenWRT based WLAN routers.

Server Installation

To install open vpn in a terminal enter:

sudo apt-get install openvpn

Public Key Infrastructure Setup

The first step in building an OpenVPN configuration is to establish a PKI (public key infrastructure). The PKI consists of:

  • a separate certificate (also known as a public key) and private key for the server and each client, and
  • a master Certificate Authority (CA) certificate and key which is used to sign each of the server and client certificates.

OpenVPN supports bidirectional authentication based on certificates, meaning that the client must authenticate the server certificate and the server must authenticate the client certificate before mutual trust is established.

Both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (CA), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server).

Certificate Authority Setup

To setup your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients first copy theeasy-rsa directory to /etc/openvpn. This will ensure that any changes to the scripts will not be lost when the package is updated. From a terminal change to user root and:

mkdir /etc/openvpn/easy-rsa/
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/

Next, edit /etc/openvpn/easy-rsa/vars adjusting the following to your environment:

export KEY_COUNTRY="US"
export KEY_PROVINCE="NC"
export KEY_CITY="Winston-Salem"
export KEY_ORG="Example Company"
export KEY_EMAIL="steve@example.com"

Enter the following to generate the master Certificate Authority (CA) certificate and key:

cd /etc/openvpn/easy-rsa/
source vars
./clean-all
./build-ca

Server Certificates

Next, we will generate a certificate and private key for the server:

./build-key-server myservername

As in the previous step, most parameters can be defaulted. Two other queries require positive responses, “Sign the certificate? [y/n]” and “1 out of 1 certificate requests certified, commit? [y/n]”.

Diffie Hellman parameters must be generated for the server:

./build-dh

All certificates and keys have been generated in the subdirectory keys/. Common practice is to copy them to /etc/openvpn/:

cd keys/
cp myservername.crt myservername.key ca.crt dh1024.pem /etc/openvpn/

Client Certificates

The VPN client will also need a certificate to authenticate itself to the server. Usually you create a different certificate for each client. To create the certificate, enter the following in a terminal while being user root:

cd /etc/openvpn/easy-rsa/
source vars
./build-key client1

Copy the following files to the client using a secure method:

  • /etc/openvpn/ca.crt
  • /etc/openvpn/easy-rsa/keys/client1.crt
  • /etc/openvpn/easy-rsa/keys/client1.key

As the client certificates and keys are only required on the client machine, you should remove them from the server.

Simple Server Configuration

Along with your OpenVPN installation you got these sample config files (and many more if if you check):

root@server:/# ls -l /usr/share/doc/openvpn/examples/sample-config-files/
total 68
-rw-r--r-- 1 root root 3427 2011-07-04 15:09 client.conf
-rw-r--r-- 1 root root 4141 2011-07-04 15:09 server.conf.gz

Start with copying and unpacking server.conf.gz to /etc/openvpn/server.conf.

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gzip -d /etc/openvpn/server.conf.gz

Edit /etc/openvpn/server.conf to make sure the following lines are pointing to the certificates and keys you created in the section above.

ca ca.crt
cert myservername.crt
key myservername.key 
dh dh1024.pem

That is the minimum you have to configure to get a working server. You can use all the default settings in the sample server.conf file. Now start the server. You will find logging and error messages in your syslog.

root@server:/etc/openvpn# /etc/init.d/openvpn start
 * Starting virtual private network daemon(s)...
   *   Autostarting VPN 'server'                     [ OK ]

Now check if OpenVPN created a tun0 interface:

root@server:/etc/openvpn# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
[...]

Simple Client Configuration

There are various different client implementations with and without GUIs. You can read more about clients in a later section. For now we use the OpenVPN client for Ubuntu which is the same executable as the server. So you have to install the openvpn package again on the client machine:

sudo apt-get install openvpn

This time copy the client.conf sample config file to /etc/openvpn/.

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/

Copy the client keys and the certificate of the CA you created in the section above to e.g. /etc/openvpn/ and edit /etc/openvpn/client.confto make sure the following lines are pointing to those files. If you have the files in /etc/openvpn/ you can omit the path.

ca ca.crt
cert client1.crt
key client1.key

And you have to at least specify the OpenVPN server name or address. Make sure the keyword client is in the config. That’s what enables client mode.

client
remote vpnserver.example.com 1194

Now start the OpenVPN client:

root@client:/etc/openvpn# /etc/init.d/openvpn start
 * Starting virtual private network daemon(s)...   
   *   Autostarting VPN 'client'                          [ OK ]

Check if it created a tun0 interface:

root@client:/etc/openvpn# ifconfig tun0
tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1

Check if you can ping the OpenVPN server:

root@client:/etc/openvpn# ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_req=1 ttl=64 time=0.920 ms

The OpenVPN server always uses the first usable IP address in the client network and only that IP is pingable. E.g. if you configured a /24 for the client network mask, the .1 address will be used. The P-t-P address you see in the ifconfig output above is usually not answering ping requests.

Check out your routes:

root@client:/etc/openvpn# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.8.0.5        0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH       0 0          0 tun0
192.168.42.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
0.0.0.0         192.168.42.1    0.0.0.0         UG        0 0          0 eth0

First trouble shooting

If the above didn’t work for you, check this:

  • Check your syslog, e.g. grep -i vpn /var/log/syslog
  • Can the client connect to the server machine? Maybe a firewall is blocking access? Check syslog on server.
  • Client and server must use same protocol and port, e.g. UDP port 1194, see port and proto config option
  • Client and server must use same config regarding compression, see comp-lzo config option
  • Client and server must use same config regarding bridged vs routed mode, see server vs server-bridge config option

Advanced configuration

ADVANCED ROUTED VPN CONFIGURATION ON SERVER

The above is a very simple working VPN. The client can access services on the VPN server machine through an encrypted tunnel. If you want to reach more servers or anything in other networks, push some routes to the clients. E.g. if your company’s network can be summarized to the network 192.168.0.0/16, you could push this route to the clients. But you will also have to change the routing for the way back – your servers need to know a route to the VPN client-network.

Or you might push a default gateway to all the clients to send all their internet traffic to the VPN gateway first and from there via the company firewall into the internet. This section shows you some possible options.

Push routes to the client to allow it to reach other private subnets behind the server. Remember that these private subnets will also need to know to route the OpenVPN client address pool (10.8.0.0/24) back to the OpenVPN server.

push "route 10.0.0.0 255.0.0.0"

If enabled, this directive will configure all clients to redirect their default network gateway through the VPN, causing all IP traffic such as web browsing and and DNS lookups to go through the VPN (the OpenVPN server machine or your central firewall may need to NAT the TUN/TAP interface to the internet in order for this to work properly).

push "redirect-gateway def1 bypass-dhcp"

Configure server mode and supply a VPN subnet for OpenVPN to draw client addresses from. The server will take 10.8.0.1 for itself, the rest will be made available to clients. Each client will be able to reach the server on 10.8.0.1. Comment this line out if you are ethernet bridging.

server 10.8.0.0 255.255.255.0

Maintain a record of client to virtual IP address associations in this file. If OpenVPN goes down or is restarted, reconnecting clients can be assigned the same virtual IP address from the pool that was previously assigned.

ifconfig-pool-persist ipp.txt

Push DNS servers to the client.

push "dhcp-option DNS 10.0.0.2"
push "dhcp-option DNS 10.1.0.2"

Allow client to client communication.

client-to-client

Enable compression on the VPN link.

comp-lzo

The keepalive directive causes ping-like messages to be sent back and forth over the link so that each side knows when the other side has gone down. Ping every 1 second, assume that remote peer is down if no ping received during a 3 second time period.

keepalive 1 3

It’s a good idea to reduce the OpenVPN daemon’s privileges after initialization.

user nobody
group nogroup

OpenVPN 2.0 includes a feature that allows the OpenVPN server to securely obtain a username and password from a connecting client, and to use that information as a basis for authenticating the client. To use this authentication method, first add the auth-user-pass directive to the client configuration. It will direct the OpenVPN client to query the user for a username/password, passing it on to the server over the secure TLS channel.

# client config!
auth-user-pass

This will tell the OpenVPN server to validate the username/password entered by clients using the login PAM module. Useful if you have centralized authentication with e.g. Kerberos.

plugin /usr/lib/openvpn/openvpn-auth-pam.so login

Please read the OpenVPN hardening security guide for further security advice.

ADVANCED BRIDGED VPN CONFIGURATION ON SERVER

OpenVPN can be setup for either a routed or a bridged VPN mode. Sometimes this is also referred to as OSI layer-2 versus layer-3 VPN. In a bridged VPN all layer-2 frames – e.g. all ethernet frames – are sent to the VPN partners and in a routed VPN only layer-3 packets are sent to VPN partners. In bridged mode all traffic including traffic which was traditionally LAN-local like local network broadcasts, DHCP requests, ARP requests etc. are sent to VPN partners whereas in routed mode this would be filtered.


PREPARE INTERFACE CONFIG FOR BRIDGING ON SERVER

Make sure you have the bridge-utils package installed:

sudo apt-get install bridge-utils

Before you setup OpenVPN in bridged mode you need to change your interface configuration. Let’s assume your server has an interface eth0 connected to the internet and an interface eth1 connected to the LAN you want to bridge. Your /etc/network/interfaces would like this:

auto eth0
iface eth0 inet static
  address 1.2.3.4
  netmask 255.255.255.248
  default 1.2.3.1

auto eth1
iface eth1 inet static
  address 10.0.0.4
  netmask 255.255.255.0

This straight forward interface config needs to be changed into a bridged mode like where the config of interface eth1 moves to the new br0 interface. Plus we configure that br0 should bridge interface eth1. We also need to make sure that interface eth1 is always in promiscuous mode – this tells the interface to forward all ethernet frames to the IP stack.

auto eth0
iface eth0 inet static
  address 1.2.3.4
  netmask 255.255.255.248
  default 1.2.3.1

auto eth1
iface eth1 inet manual
  up ip link set $IFACE up promisc on

auto br0
iface br0 inet static
  address 10.0.0.4
  netmask 255.255.255.0
  bridge_ports eth1

At this point you need to restart networking. Be prepared that this might not work as expected and that you will lose remote connectivity. Make sure you can solve problems having local access.

sudo /etc/init.d/network restart

PREPARE SERVER CONFIG FOR BRIDGING

Edit /etc/openvpn/server.conf changing the following options to:

;dev tun
dev tap
up "/etc/openvpn/up.sh br0 eth1"
;server 10.8.0.0 255.255.255.0
server-bridge 10.0.0.4 255.255.255.0 10.0.0.128 10.0.0.254

Next, create a helper script to add the tap interface to the bridge and to ensure that eth1 is promiscuous mode. Create/etc/openvpn/up.sh:

#!/bin/sh

BR=$1
ETHDEV=$2
TAPDEV=$3

/sbin/ip link set "$TAPDEV" up
/sbin/ip link set "$ETHDEV" promisc on
/sbin/brctl addif $BR $TAPDEV

Then make it executable:

sudo chmod 755 /etc/openvpn/up.sh

After configuring the server, restart openvpn by entering:

sudo /etc/init.d/openvpn restart

Client Configuration

First, install openvpn on the client:

sudo apt-get install openvpn

Then with the server configured and the client certificates copied to the /etc/openvpn/ directory, create a client configuration file by copying the example. In a terminal on the client machine enter:

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn

Now edit /etc/openvpn/client.conf changing the following options:

dev tap
;dev tun

Finally, restart openvpn:

sudo /etc/init.d/openvpn restart

You should now be able to connect to the remote LAN through the VPN.

Client software implementations

LINUX NETWORK-MANAGER GUI FOR OPENVPN

Many Linux distributions including Ubuntu desktop variants come with Network Manager, a nice GUI to configure your network settings. It also can manage your VPN connections. Make sure you have package network-manager-openvpn installed. Here you see that the installation installs all other required packages as well:

root@client:~# apt-get install network-manager-openvpn
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  liblzo2-2 libpkcs11-helper1 network-manager-openvpn-gnome openvpn
Suggested packages:
  resolvconf
The following NEW packages will be installed:
  liblzo2-2 libpkcs11-helper1 network-manager-openvpn
  network-manager-openvpn-gnome openvpn
0 upgraded, 5 newly installed, 0 to remove and 631 not upgraded.
Need to get 700 kB of archives.
After this operation, 3,031 kB of additional disk space will be used.
Do you want to continue [Y/n]?

To inform network-manager about the new installed packages you will have to restart it:

root@client:~# restart network-manager 
network-manager start/running, process 3078

Open the Network Manager GUI, select the VPN tab and then the ‘Add’ button. Select OpenVPN as the VPN type in the opening requester and press ‘Create’. In the next window add the OpenVPN’s server name as the ‘Gateway’, set ‘Type’ to ‘Certificates (TLS)’, point ‘User Certificate’ to your user certificate, ‘CA Certificate’ to your CA certificate and ‘Private Key’ to your private key file. Use the advanced button to enable compression or other special settings you set on the server. Now try to establish your VPN.

OPENVPN WITH GUI FOR MAC OS X: TUNNELBLICK

Tunnelblick is an excellent free, open source implementation of a GUI for OpenVPN for OS X. The project’s homepage is athttp://code.google.com/p/tunnelblick/. Download the latest OS X installer from there and install it. Then put your client.ovpn config file together with the certificates and keys in /Users/username/Library/Application Support/Tunnelblick/Configurations/ and lauch Tunnelblick from your Application folder.

# sample client.ovpn for Tunnelblick
client
remote blue.example.com
port 1194
proto udp
dev tun
dev-type tun
ns-cert-type server
reneg-sec 86400
auth-user-pass
auth-nocache
auth-retry interact
comp-lzo yes
verb 3
ca ca.crt
cert client.crt
key client.key

OPENVPN WITH GUI FOR WIN 7

First download and install the latest OpenVPN Windows Installer. OpenVPN 2.2.1 was the latest when this was written. Additionally download an alternative Open VPN Windows GUI. The OpenVPN MI GUI from http://openvpn-mi-gui.inside-security.de seems to be a nice one for Windows 7. Download the latest version. 20110624 was the latest version when this was written.

You need to start the OpenVPN service. Goto Start > Computer > Manage > Services and Applications > Services. Find the OpenVPN service and start it. Set it’s startup type to automatic. When you start the OpenVPN MI GUI the first time you need to run it as an administrator. You have to right click on it and you will see that option.

You will have to write your OpenVPN config in a textfile and place it in C:\Program Files\OpenVPN\config\client.ovpn along with the CA certificate. You could put the user certificate in the user’s home directory like in the follwing example.

# C:\Program Files\OpenVPN\config\client.ovpn
client
remote server.example.com
port 1194
proto udp
dev tun
dev-type tun
ns-cert-type server
reneg-sec 86400
auth-user-pass
auth-retry interact
comp-lzo yes
verb 3
ca ca.crt
cert "C:\\Users\\username\\My Documents\\openvpn\\client.crt"
key "C:\\Users\\username\\My Documents\\openvpn\\client.key"
management 127.0.0.1 1194
management-hold
management-query-passwords
auth-retry interact

OPENVPN FOR OPENWRT

OpenWRT is described as a Linux distribution for embedded devices like WLAN router. There are certain types of WLAN routers who can be flashed to run OpenWRT. Depending on the available memory on your OpenWRT router you can run software like OpenVPN and you could for example build a small inexpensive branch office router with VPN connectivity to the central office. More info on Open VPN on OpenWRT is here. And here is the OpenWRT project’s homepage: http://openwrt.org

Log into your OpenWRT router and install OpenVPN:

opkg update
opkg install openvpn

Check out /etc/config/openvpn and put you client config in there. Copy certificated and keys to /etc/openvpn/

config openvpn client1
        option enable 1                                  
        option client 1                                  
#       option dev tap                                   
        option dev tun  
        option proto udp   
        option ca /etc/openvpn/ca.crt                
        option cert /etc/openvpn/client.crt
        option key /etc/openvpn/client.key
        option comp_lzo 1

Restart server:

/etc/init.d/openvpn restart

You will have to see if you need to adjust your router’s routing and firewall rules.

Setup and Configure a L2TPServer on Linux Ubuntu


Ubuntu: L2TPServer

This Guide will walk you through the process of installing a L2TP VPN Server on Ubuntu Server This configuration has been successfully tested with Android, Windows, and iOS devices.


Instructions

sudo apt-get install xl2tpd openswan ppp

IPSec / Openswan

In the /etc/ipsec.conf file copy:

config setup
    nat_traversal=yes
    virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!10.152.2.0/24
    #contains the networks that are allowed as subnet= for the remote client. In other words, the address ranges that may live behind a NAT router through which a client connects.
    oe=off
    protostack=netkey

conn L2TP-PSK-NAT
    rightsubnet=vhost:%priv
    also=L2TP-PSK-noNAT

conn L2TP-PSK-noNAT
    authby=secret
    pfs=no
    auto=add
    keyingtries=3
    rekey=no
    # Apple iOS doesn't send delete notify so we need dead peer detection
    # to detect vanishing clients
    dpddelay=30
    dpdtimeout=120
    dpdaction=clear
    # Set ikelifetime and keylife to same defaults windows has
    ikelifetime=8h
    keylife=1h
    type=transport
    # Replace IP address with your local IP (private, behind NAT IP is okay as well)
    left=x.x.x.x
    # For updated Windows 2000/XP clients,
    # to support old clients as well, use leftprotoport=17/%any
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    #force all to be nat'ed. because of iOS
    forceencaps=yes

Make sure you follow the setup in the ipsec.conf file, the part “config setup” and “conn l2tp-psk” should be to the very left while the other text 8 spaces to the right.

In the “/etc/ipsec.secrets” file copy:

x.x.x.x   %any:  PSK "somegoodpassword"

Replace x.x.x.x with your Server’s IP

Start the IPSEC service with

/etc/init.d/ipsec start

Please verify the IPSEC service with :

sudo ipsec verify

you must get no errors.

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.28/K2.6.32-32-generic-pae (netkey)
Checking for IPsec support in kernel                            [OK]
NETKEY detected, testing for disabled ICMP send_redirects       [OK]
NETKEY detected, testing for disabled ICMP accept_redirects     [OK]
Checking that pluto is running                                  [OK]
Pluto listening for IKE on udp 500                              [OK]
Pluto listening for NAT-T on udp 4500                           [OK]
Checking for 'ip' command                                       [OK]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

Create a file called “ipsec.vpn” in “/etc/init.d/”

case "$1" in
  start)
echo "Starting my Ipsec VPN"
iptables  -t nat   -A POSTROUTING -o eth0 -s 10.152.2.0/24 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
done
/etc/init.d/ipsec start
/etc/init.d/xl2tpd start
;;
stop)
echo "Stopping my Ipsec VPN"
iptables --table nat --flush
echo 0 > /proc/sys/net/ipv4/ip_forward
/etc/init.d/ipsec stop
/etc/init.d/xl2tpd stop
;;
restart)
echo "Restarting my Ipsec VPN"
iptables  -t nat   -A POSTROUTING -o eth0 -s 10.152.2.0/24 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward
for each in /proc/sys/net/ipv4/conf/*
do
    echo 0 > $each/accept_redirects
    echo 0 > $each/send_redirects
done
/etc/init.d/ipsec restart
/etc/init.d/xl2tpd restart

;;
  *)
 echo "Usage: /etc/init.d/ipsec.vpn  {start|stop|restart}"
 exit 1
  ;;
esac

This will configure the firewall forwarding. If you use a local IP pool other than 10.152.2, be sure to update it.

Then set the permission to execute:

sudo chmod 755 ipsec.vpn

Disable the ipsec default init script with

#update-rc.d -f ipsec remove

And enable the custom one.

#update-rc.d ipsec.vpn defaults

L2TP

In the file /etc/xl2tpd/xl2tpd.conf

[global]
ipsec saref = no

[lns default]
ip range = 10.152.2.2-10.152.2.254
local ip = 10.152.2.1
require chap = yes
refuse pap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes
  • ip range = range of IP’s to give to the connecting clients
  • local ip = IP of VPN server. Value must be outside of “ip range”.
  • refuse pap = refure pap authentication
  • ppp debug = yes when testing, no when in production

Choose a good challenge-response authentication string. The secret should, ideally, be 16 characters long, and should probably be longer to ensure sufficient security. There is no minimum length requirement. In the file /etc/xl2tpd/l2tp-secrets:

* * exampleforchallengestring

In the file /etc/ppp/options.xl2tpd copy:

refuse-mschap-v2
refuse-mschap
ms-dns 8.8.8.8
ms-dns 8.8.4.4
asyncmap 0
auth
crtscts
idle 1800
mtu 1200
mru 1200
lock
hide-password
local
#debug
name l2tpd
proxyarp
lcp-echo-interval 30
lcp-echo-failure 4

ms-dns option

Here you set the dns server for your lan, this dns server are pushed to the road warrior when he connects. If you wan to add several servers just add several lines. If you need to push wins settings to the clients there is an separate option for that.

mtu / mru

openswan suggest that it’s important to reduce the mru/mtu size because l2tp/ipsec are encapsulated several times it causes overhead. Reducing this makes it possible to transmit all packages over lines with reduced mtu size.

proxyarp

Adds an entry to this system’s ARP [Address Resolution Protocol] table with the IP address of the peer and the Ethernet address of this system. This will have the effect of making the peer appear to other systems to be on the local ethernet.

name l2tpd

Is used in the ppp authentication file.

Adding Users

In the file /etc/ppp/chap-secrets copy:

user1 l2tpd chooseagoodpassword *
user2 * chooseagoodpassword *
  • client = username for the user
  • server = the name we define in the ppp.options file for xl2tpd
  • secret = password for the user
  • IP Address = leave to * for any address or define addresses from were a user can login.

Note: you can add as many user you like.


Forward

in /etc/sysctl.conf

net.ipv4.ip_forward=1

Load the new settings made in /etc/sysctl.conf

sysctl -p

Starting the VPN

sudo /etc/init.d/ipsec.vpn restart
sudo /etc/init.d/xl2tpd restart

Connecting the VPN to iOS device

  1. Go to Settings > General > Network > VPN > Add VPN Configuration > L2 TP
  2. VPN Description > the name you like
  3. Set VPN server > external ip address of the VPN server (x.x.x.x)
  4. Account > PPP username
  5. Set password > somegoodpassword
  6. Set L2T P Secret > was exampleforchallengestring
  7. Connect using the PPP username/password (user1 chooseagoodpassword)

Connecting the VPN to an Android device

  1. Go to Settings > Wireless & networks > VPN settings > Add VPN > Add L2TP/IPSec PSK VPN >
  2. VPN Name / Description > the name you like
  3. Set VPN server > external ip address of the VPN server (x.x.x.x)
  4. Set IPSec pre-shared key / password > somegoodpassword
  5. Enable L2TP secret > enable
  6. Set L2TP Secret > was exampleforchallengestring
  7. Press back, then connect using the PPP username/password (user1 chooseagoodpassword)

Debug

In case of problems this are a few commands that can help out the debugging.

sudo tcpdump -i ppp0
sudo tail -f /var/log/auth.log
sudo tail -f /var/log/syslog

You can also monitor the results on the Server with

sudo tcpdump -i eth0 host aaa.bbb.ccc.ddd and not port ssh

aaa.bbb.ccc.ddd are the public IP address of your Clients

Bitcoin-qt I2P


Bitcoin-qt I2P


This project describes modifications of the standard bitcoin client (https://github.com/bitcoin/bitcoin) to allow it to work through I2P-network without any third-party tools.

Installation on Linux (Ubuntu 12.04)

add ppa for i2p and bitcoin

sudo apt-add-repository ppa:i2p-maintainers/i2p
sudo apt-add-repository ppa:bitcoin/bitcoin

update

sudo apt-get update
sudo apt-get upgrade

install packages (java will be installed by dependencies)

sudo apt-get install i2p bitcoin-qt

edit  /etc/default/i2p with root privileges

 RUN_DAEMON="true"  <- set to true
...
  MEMORYLIMIT="xxx"  <- specify a value subject to your operative memory (256 or 512 shoud be enough)

Run i2p

sudo service i2p start


Installation on Windows

  • Download an i2p distribution kit from the official site: http://www.i2p2.de/download
  • You should also download Java from official site too http://java.com/download/
  • First install Java, then install I2P
  • go to Control Panel – Administrative tools – Services, find “I2P” and check it is running (if it isn’t running you should run it)


Running bitcoin :: i2p (both Windows and Linux)

  • after I2P is started you should wait a few minutes while i2p integrate in the network
  • in your browser open the page http://127.0.0.1:7657/configclients. If the page is unavailable I2P is not running. If the page opens you should press “Start” button near “SAM application bridge” item and enable a checkbox in column “Run at Startup?” After that press “Save Client Configuration” button.
  • delete (or rename) file peers.dat, it’s located in C:\Documents and Settings\<YourUserName>\Application data\Bitcoin (for Win XP)  | C:\Users\<YourUserName>\Appdata\Roaming\Bitcoin (for Vista and 7) | ~/.bitcoin (for linux).
  • You must to do this because serialization format of network addresses is incompatible between the vanilla client and the patch. You need to do this procedure only once before the first start of the patched client. The patched client will make his own peers.dat with required format. Warning! If you leave this file at his place it cause a deadlock of the patched client.
  • Download the patched executable files or compile the executable files by yourself and run it  bitcoin-qt -onlynet=native_i2p

If you want to deal with i2p-net only you should specify option -onlynet=native_i2p as shown above. If you want to deal with both i2p and ip don’t specify this option at all, in this case your client will be a gate between i2p-segment of bitcoin-net and the rest net.

Changes in command line arguments

New command line options are added:

-i2psessionname=<session name> - name of an I2P session. If it is not specified, value will be "Bitcoin-client"
-samhost=<ip or host name> - address of the SAM bridge host. If it is not specified, value will be "127.0.0.1"
-samport=<port> - port number of the SAM bridge host. If it is not specified, value will be "7656".
-mydestination=<pub+priv i2p-keys> - your full destination (public+private keys). If it is not specified, the client will geneterate a random destination for you. See below (Starting wallet with a permanent i2p-address) more details about this option.
-generatei2pdestination - if this option is specified, your client will start for generation i2p-destination only and will close after that.

2) New possible value for “-onlynet” option is added:

native_i2p

In all options required IP-addresses you can specify destination hash: <512 symbols>AAAA or b32-address: <52 symbols>.b32.i2p


Compatibility

  • The rest of the options (except of those described above) are not changed and they are working as they did before
  • Database-file peers.dat is not compatible in both way, neither from vanilla client to the patch, nor from the patch to vanilla client. This file must be deleted (or renamed) before using the patch and before going back to vanilla client. This file doesn’t contain any important data, so you don’t need to back up it.
  • The othe databases are compatible with vanilla client.
  • Full backward compatibility with the bitcoin-protocol! Patched client works fine with unpatched vanilla clients. Changes in the protocol appeared only if both clients are patched.

Starting wallet with a permanent I2P-address

By default if you don’t specify -mydestination parameter the patched wallet generates random i2p-destination. It can anonymize your work with bitcoin even more – especially if you use a new bitcoin-address for each transaction. But if you want to help the network [or you just like some i2p-address[ you will have to run wallet with permanent i2p-address. For that, you will have to specify a full destination in the “mydestination” optiont. Full destionation consists of base64 destionation (b32-address is not allowed here!) and your private tunnel key.
Example:

bitcoin-qt -mydestination=SVAxpjZzKn~HjvuqpoX5Y948CQnrPpw~9Y9n7itkniijx3NbgTQGJVmZJoc1ERXE87CqcLeeaWtAwqIwhYXL5Y5XkvaUAlAA5BD-9afCmyP42rtEluQLBAprd70UuN20ujuVm0HPyKcIyezphMHsK~GbYMNFiyTz8ko~Kd2wHaeXKWQh6pXyjQJzT4Bwcv1Y9JtPC5b1P5VpwQaLlMJJvblRi8jbRAbimjsxxrMSG6YX8Ks99tsdnQ6YOHGzTPoGpHFgBiROSYwXtC~BbFSv0XfhmN17ZfG6ZCXTbp-xVs-4txSyS~hnS9dL9xHWIv9MNbJzZhI7YztxWgMR3ZNMwR-W2fUeHAcZusmvbm3r-NpIC0O0p9LDDcu7Vxszk~QD~qylFfIT3j8kwu4RDExgqyelVdXVVSlyriHWoIdt9BklqwI1dbAEoLAfG7IZ3921dP4-MH7~AS8Jn3foNe8CAUvu2baRNRIAu75GknCFV5gGIuRRJjFNnrt~vaZfIQP6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3HWfbGlqztnwMY3ChbVHkDwJv52n9ElA-cWCRJp8lquVU4H-l2kY5Me1QlpY~7qFy

Or you may use your config-file (bitcoin.conf):

$ cat ~/.bitcoin/bitcoin.conf
mydestination=SVAxpjZzKn~HjvuqpoX5Y948CQnrPpw~9Y9n7itkniijx3NbgTQGJVmZJoc1ERXE87CqcLeeaWtAwqIwhYXL5Y5XkvaUAlAA5BD-9afCmyP42rtEluQLBAprd70UuN20ujuVm0HPyKcIyezphMHsK~GbYMNFiyTz8ko~Kd2wHaeXKWQh6pXyjQJzT4Bwcv1Y9JtPC5b1P5VpwQaLlMJJvblRi8jbRAbimjsxxrMSG6YX8Ks99tsdnQ6YOHGzTPoGpHFgBiROSYwXtC~BbFSv0XfhmN17ZfG6ZCXTbp-xVs-4txSyS~hnS9dL9xHWIv9MNbJzZhI7YztxWgMR3ZNMwR-W2fUeHAcZusmvbm3r-NpIC0O0p9LDDcu7Vxszk~QD~qylFfIT3j8kwu4RDExgqyelVdXVVSlyriHWoIdt9BklqwI1dbAEoLAfG7IZ3921dP4-MH7~AS8Jn3foNe8CAUvu2baRNRIAu75GknCFV5gGIuRRJjFNnrt~vaZfIQP6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3HWfbGlqztnwMY3ChbVHkDwJv52n9ElA-cWCRJp8lquVU4H-l2kY5Me1QlpY~7qFy

The first 516 symbols (SVAxp……~vaZfIQP6AAAA) are the public key. This key is a base64 i2p-address (aka dest-hash). The rest of the symbols are private key. If you want to use some i2p-address you need to know its private key. If you publish you private i2p-key anyone can use your i2p-address. So keep secret your private key. This program does not send your private key, it uses your key only to open i2p-tunnel. A simplest way to generate your own I2P-address is by running the patched client with the option -generatei2pdestination. A generated address with a private key will be shown and you will can copy it to your config-file and publish it.

Building from the sources on Linux

Install all necessary libraries for bitcoin. No additional dependencies are needed. Go to a root directory of the project and run 1.build-unix.sh

./1.build-unix.sh


Crosscompillation for Windows on Linux

Install mingw32

apt-get install mingw32

Download and unpack dependencies using script 1.env-setup.sh

/1.env-setup.sh

Build dependencies by script 2.build-deps.sh

./2.build-deps.sh

Build bitcoin with i2p-patch using 3.build-linux-mingw.sh

./3.build-linux-mingw.sh

All builded binaries will be located at <directory with project>/release. I don’t have native windows build scripts, because I used crosscompilation as shown above.

This program is provided “as is” without any warranties. Get it here

Raspberry Pi – OpenVPN


OpenVPN: Raspberry Pi

If you are in a public network, for example at university or the airport, your traffic can be recorded and decrypted. To prevent others from doing that you can send your traffic through a secured VPN-tunnel. The VPN-tunnel leads your traffic encrypted to a server which is processing your requests.

In the following tutorial you will learn how to run OpenVPN Server on your Raspberry Pi:

Requirements

Raspbian or a similar distribution.

Step 1

To be able to install the latest program versions we should update our packet sources:

sudo apt-get update

Step 2

Now we are installing Open VPN and OpenSSL.

sudo apt-get install openvpn openssl

Step 3

We are switching to the directory and paste a directory we will be needing later into it.

cd /etc/openvpn
sudo cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 ./easy-rsa

Step 4

Now we open the file easy-rsa/vars with nano and apply some changes.

nano /easy-rsa/vars 
export EASY_RSA="`pwd`"
export EASY_RSA="/etc/openvpn/easy-rsa"

Step 5

We change the directory, log in as root user and execute some configurations.

cd easy-rsa
sudo su
source vars
./clean-all
./pkitool --initca
ln -s openssl-1.0.0.cnf openssl.cnf

Step 6

Now we are able to generate the components for the encryption of Open VPN. After the first input you will be asked for the abbreviation of your country (US = USA, DE – Germany, AT = Austria, CH – Switzerland). All other inputs can simply be confirmed.

./build-ca OpenVPN
./build-key-server server
./build-key client1

Step 7

The calculation of the last components can take a few minutes.

./build-dh
exit

Step 8

We have to switch the directory again and create the file openvpn.conf with the following content:

cd ..
sudo touch openvpn.conf
sudo nano openvpn.conf

dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
user nobody
group nogroup
server 10.8.0.0 255.255.255.0
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 3
client-to-client
push "redirect-gateway def1"
#set the dns servers
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
log-append /var/log/openvpn
comp-lzo

You can change the DNS-servers to any DNS you like.

Step 9

Now, create the internet-forwarding for the CPN clients. If you are not using an ethernet-cable (e.g. Wifi) you will have to replace “eth0″ with the name of your network device.

sudo sh -c ‘echo 1 > /proc/sys/net/ipv4/ip_forward’
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/8 ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE

Step 10

One of the final steps will be to delete the “#” before net.ipv4.ip_forward=1 in sysctl.conf.

cd ..
sudo nano sysctl.conf

Step 11

A part of the above settings have to be endorsed as a crontab to work permanently. Insert following line at the end of the crontab file (replace “eth0″ if you did above):

crontab -e

@reboot sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/8 ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE

Step 12

Again change to the root-user and to the directory /etc/openvpn/easy-rsa/keys in which we will create the fileraspberrypi.ovpn and fill it with the code of the second paragraph. RASPBERRY-PI-IP should be replaced by the IP address of your Pi or, if you are using a DynDNS service,  by the given domain.

sudo su
cd /etc/openvpn/easy-rsa/keys
nano raspberrypi.ovpn

dev tun
client
proto udp
remote RASPBERRY-PI-IP 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 3

Step 13

Now create a packet with all the needed files for the client, which we will place in /home/pi and give the user pi the needed rights to the file.

tar czf openvpn-keys.tgz ca.crt ca.key client1.crt client1.csr client1.key raspberrypi.ovpn
mv openvpn-keys.tgz /home/pi
chown pi:pi /home/pi/openvpn-keys.tgz
exit

Step 14

Restart the server.

sudo /etc/init.d/openvpn start

Finished! Now we are able to download the file die openvpn-keys.tar.gz on the client and extract the files to your Open VPN client folder.

An Open VPN Client for Windows is: http://openvpn.se/
for Mac: https://code.google.com/p/tunnelblick/

Linux users simply install the packet openvpn

PGP Ubuntu


PGP Ubuntu

“GnuPG uses public-key cryptography so that users may communicate securely. In a public-key system, each user has a pair of keys consisting of a private key and a public key. A user’s private key is kept secret; it need never be revealed. The public key may be given to anyone with whom the user wants to communicate.” From The GNU Privacy Handbook

GnuPG, GPG, PGP and OpenPGP

The terms “OpenPGP“, “PGP“, and “GnuPG / GPG” are often used interchangeably. This is a common mistake, since they are distinctly different.

  • OpenPGP is technically a proposed standard, although it is widely used. OpenPGP is not a program, and shouldn’t be referred to as such.
    • PGP and GnuPG are computer programs that implement the OpenPGP standard.
  • PGP is an acronym for Pretty Good Privacy, a computer program which provides cryptographic privacy and authentication.
  • GnuPG is an acronym for Gnu Privacy Guard, another computer program which provides cryptographic privacy and authentication.

Generating an OpenPGP Key

The core package required to start using OpenPGP, gnupg, is installed by default on Ubuntu systems, as is seahorse, a GNOME application for managing keys. It is called “Passwords and Keys” in Ubuntu.

There are several programs which provide a graphical interface to the GnuPG system.

  • Enigmail, an OpenPGP plugin for Mozilla Thunderbird.
    • Enigmail was available in the “Main” repository through Intrepid, but can be found in the “Universe” repository since Jaunty.
sudo apt-get install enigmail
  • GNU Privacy Assistant is a graphical user interface for the GnuPG (GNU Privacy Guard).
    • GPA is available in the “Universe” repository. See Repositories for further information on enabling repositories.
sudo apt-get install gpa
  • Seahorse is a GNOME application for managing encryption keys. It also integrates with nautilus, gedit, and in other places for encryption operations.
    • Seahorse is available in the “Main” repository.
sudo apt-get install seahorse
  • KGPG is a simple, free, open source KDE frontend for gpg.
    • KGPG is available in the “Main” repository since Intrepid, or the “Universe” repository in earlier releases.
sudo apt-get install kgpg
  • Kleopatra is another KDE frontend for gpg that is integrated with the KDE PIM (although you need to install it separately for now).
    • Kleopatra is available in the “Universe” repository and it includes S/MIME backend:
sudo apt-get install kleopatra

Using GnuPG to generate a key

  • Open a terminal and enter:
    gpg --gen-key
    • If you are using gnupg version 1.4.10 or newer, this will lead to a selection screen with the following options:
      Please select what kind of key you want:
         (1) RSA and RSA (default)
         (2) DSA and Elgamal
         (3) DSA (sign only)
         (4) RSA (sign only)
    • Select (1), which will enable both encryption and signing.
    • If you are using an older version, the selection screen will have the following options:
      Please select what kind of key you want:
         (1) DSA and Elgamal (default)
         (2) DSA (sign only)
         (5) RSA (sign only)
    • We suggest you select (5). We will generate an encryption subkey later.
    What keysize do you want? (2048)
  • A keysize of 2048 (which is the default) is also a good choice.
    Key is valid for? (0)
  • Most people make their keys valid until infinity, which is the default option. If you do this don’t forget to revoke the key when you no longer use it (see below).
  • Hit Y and proceed.
    You need a user ID to identify your key; the software constructs the user ID
    from the Real Name, Comment and Email Address in this form:
        "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
    
    Real name: Dennis Kaarsemaker
    Email address: dennis@kaarsemaker.net
    Comment: Tutorial key
    You selected this USER-ID:
        "Dennis Kaarsemaker (Tutorial key) <dennis@kaarsemaker.net>"
  • Make sure that the name on the key is not a pseudonym, and that it matches the name in your passport, or other government issued photo-identification! You can add extra e-mail addresses to the key later.
  • Type O to create your key.
    You need a Passphrase to protect your secret key.
  • You will be asked for your passphrase twice. Usually, a short sentence or phrase that isn’t easy to guess can be used. You would be asked to tap on the keyboard or do any of the things you normally do in order for randomization to take place. This is done so that the encryption algorithm has more human-entered elements, which, combined with the passphrase entered above, will result in the user’s private key.

Forgetting your passphrase will result in your key being useless.
Carefully memorize your passphrase

  • After you type your passphrase twice, the key will be generated. Please follow the instructions on the screen till you reach a screen similar to the one below.
    gpg: key D8FC66D2 marked as ultimately trusted
    public and secret key created and signed.
    
    pub   1024D/D8FC66D2 2005-09-08
          Key fingerprint = 95BD 8377 2644 DD4F 28B5  2C37 0F6E 4CA6 D8FC 66D2
    uid                  Dennis Kaarsemaker (Tutorial key) <dennis@kaarsemaker.net>
    sub   2048g/389AA63E 2005-09-08

The key-id is D8FC66D2 (yours will be different).

It is probably a good idea to set this key as default in your .bashrc.
Doing this will allow applications using GPG to automatically use your key

  • Set your key as the default key by entering this line in your ~/.bashrc.
    export GPGKEY=D8FC66D2
    • Please note that will be sourced only during your next session, unless you source it manually.
  • Now restart the gpg-agent and source your .bashrc again:
    killall -q gpg-agent
    eval $(gpg-agent --daemon)
    source ~/.bashrc

Encryption

  • If you created an “RSA (sign only)” earlier, you will probably want to add encryption capabilities. Assuming you edited ~/.bashrc as above, open a terminal again and enter:
    gpg --cert-digest-algo=SHA256 --edit-key $GPGKEY
  • This will present a dialog like the following:
    Secret key is available.
    
    pub   2048R/D8FC66D2  created: 2005-09-08  expires: never       usage: SC  
                         trust: ultimate      validity: ultimate
    [ultimate] (1). Dennis Kaarsemaker (Tutorial key) <dennis@kaarsemaker.net>
    
    Command>
  • To create a subkey, enter ‘addkey’. You will have to enter your key’s passphrase, and then you’ll see a somewhat familiar series of dialogues:
    Please select what kind of key you want:
       (2) DSA (sign only)
       (4) Elgamal (encrypt only)
       (5) RSA (sign only)
       (6) RSA (encrypt only)
  • Choose 6.
    What keysize do you want? (2048)
  • Again, 2048 is a sensible default.
    Key is valid for? (0)
  • Choose whether this encryption subkey is set to expire (default: it doesn’t). Then confirm that you want to make this subkey.
    pub   2048R/D8FC66D2  created: 2005-09-08  expires: never       usage: SC  
                         trust: ultimate      validity: ultimate
    sub   2048R/389AA63E created: 2005-09-08  expires: never       usage: E   
    [ultimate] (1). Dennis Kaarsemaker (Tutorial key) <dennis@kaarsemaker.net>
    Command>
  • Enter ‘save’, then ‘quit.’ Your key is now capable of encryption.

Creating a revocation key/certificate

  • A revocation certificate must be generated to revoke your public key if your private key has been compromised in any way.
  • It is recommended to create a revocation certificate when you create your key. Keep your revocation certificate on a medium that you can safely secure, like a thumb drive in a locked box.
  • You can create a revocation certificate by :
    gpg --output revoke.asc --gen-revoke $GPGKEY
  • The revocation key may be printed and/or stored as a file. Take care to safeguard your revocation key.

Anybody having access to your revocation certificate can revoke your key, rendering it useless

Making an ASCII armored version your public key

There are several sites out there that also allow you to paste an ASCII armored version your public key to import it. This method is often preferred, because the key comes directly from the user. The reasoning behind this preference is that a key on a keyserver may be corrupted, or the keyserver unavailable.

  • Create an ASCII armored version of your public key using GnuPG by using this command:
gpg --output mykey.asc --export -a $GPGKEY

This is the command using our example:

gpg --output mykey.asc --export -a D8FC66D2

Getting your key signed

The whole point of all this is to create a web of trust. By signing someone’s public key, you state that you have checked that the person that uses a certain keypair, is who he says he is and really is in control of the private key. This way a complete network of people who trust each other can be created. This network is called the Strongly connected set. Information about it can be found at http://pgp.cs.uu.nl/

In summary,

  1. Locate someone that lives near you and can meet with you to verify your ID.
  2. Arrange for a meeting. Bring at least one ID with photo and printed fingerprint of your OpenPGP key, ask the same from the person you will be meeting with.
  3. Print copies of your public key
    • get the last eight digits of your fingerprint: 0995 ECD6 3843 CBB3 C050 28CA E103 6EED 0123 4567
    • terminal: gpg –fingerprint 01234567 >> key.txt
    • print the resulting key.txt file and bring as many copies to the meeting as you expect to have people sign
  4. Meet, verify your IDs and exchange OpenPGP key fingerprints
  5. Sign the key of the person you’ve just met. Send him/her the key you’ve just signed.
  6. Update your keys on the keyserver, the signature you’ve just created will be uploaded.

Keysigning Guidelines

Since a signature means that you checked and verified that a certain public key belongs to a certain person who is in control of the accompanying private key, you need to follow these guidelines when signing peoples keys:

During the Event

  1. Keysigning is always done after meeting in person
  2. During this meeting you hand each other your OpenPGP key fingerprint and at least one government issued ID with a photograph. These key fingerprints are usually distributed as key fingerprint slips, created by a script such as gpg-key2ps (package: signing-party)
  3. You check whether the name on the key corresponds with the name on the ID and whether the person in front of you is indeed who he says he is.

After the Event

You now have the printed public key information from the other participants.

Example key IDs for the other participants will be E4758D1D, C27659A2, and 09026E7B. Replace these IDs with the key IDs you received from the other participants.

  1. retrieve the keys:
    • gpg –recv-keys E4758D1D C27659A2 09026E7B
  2. sign the keys:
    • gpg –sign-key E4758D1D
    • gpg –sign-key C27659A2
    • gpg –sign-key 09026E7B
  3. export the keys
    • gpg –armor –export E4758D1D –output E4758D1D.signed-by.01234567.asc
    • gpg –armor –export C27659A2 –output C27659A2.signed-by.01234567.asc
    • gpg –armor –export 09026E7B –output 09026E7B.signed-by.01234567.asc
  4. Email the key users (use the email address that was part of the key’s user ID) and attach the corresponding signature file – or – send their signed key to the key server:
    • gpg –send-keys –keyserver keyserver.ubuntu.com E4758D1D
  5. Once you receive your signed key import them to your keyring:
    • gpg –import 01234567.signed-by.E4758D1D.asc
    • gpg –import 01234567.signed-by.C27659A2.asc
    • gpg –import 01234567.signed-by.09026E7B.asc
  6. You should see your keys:
    • gpg –list-sigs 01234567
  7. Send your keys to the keyserver:
    • gpg –send-keys 01234567

Congrats you have now entered a web of trust or enlarged an existing one.

Backing up and restoring your key pair

Why should you back up your key pair? If you lose your key pair:

  • Any files encrypted with the lost key pair will be unrecoverable.
  • You will not be able to decrypt mails sent to you.
    • Decrypting emails sent to you requires your private key, this key is not stored on the keyservers.

If you lose your keypair you should revoke your key. This cannot be done without a revocation key.

Backing up your public key

  • List your public keys:
    gpg --list-keys
  • Look for the line that starts something like “pub 1024D/”. The part after the 1024D is the key_id. To export the key:
    gpg -ao _something_-public.key --export key_id

Backing up your private key

  • List your secret keys:
    gpg --list-secret-keys
  • Look for the line that starts something like “sec 1024D/”. The part after the 1024D is the key_id. To export the secret key:
    gpg -ao _something_-private.key --export-secret-keys key_id

Restoring your keys

  • To restore your keys – copy the two files created above to the machine and type:
    gpg --import _something_-public.key
    gpg --import _something_-private.key

Make sure you protect these files!

Revoking a keypair

In the event your keys are lost or compromised, you should revoke your keypair. This tells other users that your key is no longer reliable.

 For security purposes, there is no mechanism in place to revoke a key without a revocation key. As much as you might want to revoke a key, the revocation key prevents malicious revocations. Guard your revocation key with the same care you would use for your private key.
  • To revoke your key you need to first create a revocation key with the command:
gpg --gen-revoke
  • Import your revocation key, which would be stored to the file revoke.asc by default:
gpg --import revoke.asc
  • Upload the revocation key to your keyserver of choice, in the following example the key will be send to ubuntus keyserver:
gpg --keyserver keyserver.ubuntu.com --send-key 6382285E

Un-revoking a keypair

If you unintentionally revoke a key, or find that your key has in fact not been lost or compromised, it is possible to un-revoke your key. First and foremost, ensure that you do not distribute the key, or send it to the keyserver.

  • Export the key
gpg --export <key> > key.gpg
  • Split the key into multiple parts. This breaks the key down into multiple parts.
gpgsplit key.gpg
  • Find which file contains the revocation key. In most cases, it is 000002-002.sig, however you should make sure by using the following. If the sigclass is 0x20, you have the right file. Delete it.
gpg --list-packets 000002-002.sig
  • Put the key back together
cat 0000* > fixedkey.gpg
  • Remove the old key
gpg --expert --delete-key <key>
  • Import the new key
gpg --import fixedkey.gpg

GPG 2.0

GPG 2.0 is not installed as a default application on Ubuntu.

GPG 2.0 is the new kid on the block. GPG 2.0 is aimed or done for the desktops rather than embedded or server applications.

  • GnuPG2 is available in the “Main” repository since Intrepid, or in the “Universe” repository in earlier releases.
    • If you want to use gnupg2 with the firegpg firefox extension, you need to install gnupg2 first.
  • More information of GnuPG2 can be found here
  • If you are going to use gpg2 for the same purposes as outlined above then you just need to add 2 to the gpg command.
    gpg2 --gen-key

Using GPG To Sign SSH Keys

Often to access a remote server by SSH the administrator of the server will ask for your public ssh_rsa key so that he knows it is really your computer that is trying to access his server. The administrator may ask you to first sign the ssh_rsa key using GPG so that he knows the ssh_rsa key comes from you and has not been intercepted. This guide will show you how to generate your SSH and GPG keys and then how to use them to perform a secure transaction between two parties.

Ubuntu Releases

This guide should work on any Gnu/Linux operating system. This guide assumes you have already installed openssh-client and gnupg.

Generate The SSH RSA Keys

Run all commands as a regular user.

# ssh-keygen -t rsa

This will create your public and private SSH-RSA keys. The public key that the administraitor needs should be located here: ~/.ssh/id_rsa.pub.

Generate The GPG Keys

This is the output from generating a new key.

# gpg --cert-digest-algo SHA256 --default-preference-list "h10 h8 h9 h11 s9 s8 s7 s3 z2 z3 z1 z0" --gen-key
gpg (GnuPG) 1.4.6; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection? 5
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct (y/n)? y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: mr bo jangles
Email address: bo@jangles.com
Comment: comment
You selected this USER-ID:
   "mr bo jangles (comment) <bo@jangles.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

#-> passphrase:

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.+++++++++++++++.+++++++++++++++.+++++.++++++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++++++++++++++++++++++.++++++++++..+++++++++++++
public and secret key created and signed.
key marked as ultimately trusted.

pub  2048R/5F6D1662 2009-05-10 mr bo jangles (comment) <bo@jangles.com>
    Key fingerprint = D1BC 6822 0ACB 0025 8902  6DE7 87EA 4324 5F6D 1662

Your public and private GPG keys should now be located in your ~/.gnupg directory.

Put your private key on a cd-rom or a floppy disc or somewhere very safe. Do not lose it or you will be unable to sign any documents. Never give it to anyone under any circumstances. If you have given anyone your private key then you must revoke the key immediately and generate a new set.

Exchange Public Keys

It is good practice to put your public GPG key on a public key server where others can access it easily. Biglumber.com is a public key server. In order to put your public key on Biglumber you will first need to go though a verification process.

Go to Biglumber.com and put your public key on their server.

While you are at Biglumber you will need to find the public key of the administrator to whom you are planning to send your digitally signed and encrypted message. Once you have done that, you must then import the pubic key of that administrators into your keyring.

# gpg --import Administrator.pub

Now get the Administrator’s key ID, and your key ID as well:

# gpg --list-keys
pub  1024D/ABCABCAB 2005-03-26 Administrator_Email <admin@secure.ca>
pub  2048R/XYZXYZXY 2009-05-10 Your_Email_Address <user@user.ca>

Aministrator ID: ABCABCAB

Your ID: XYZXYZXY

Make a Secure Transaction

GPG will use your secret key (~/.gnupg/secring.gpg) to sign and encrypt your public ssh key (~/.ssh/id_rsa.pub).

Only the administrator will be able to decrypt the file because you are also using his public key to encrypt it.

In turn, he will only be able to decrypt it if he has your public key on his key ring.

Sign the key:

# gpg -u XYZXYZXY -r ABCABCAB --armor --sign --encrypt ~/.ssh/id_rsa.pub

Send the result (id_rsa.pub.gpg) to the administrator along with a link to where you keep your public key on Biglumber. He will verify the your information and then allow you to access his system by SSH.

In an ideal world you are only supposed to exchange public keys directly and in person. This way you know 100% that the public key truly belongs to the correct person.

How To Encrypt Bash Scripts


How to Encrypt Bash Script

if you want to encrypt your bash script for some reason, you can do that with SHC utility. Encrypting your script with SHC provides you with a basic type of protection. Please note that the encrypted shell script created by shc is not readable by a regular users but a skilled user can extract the original shell script from the encrypted binary. General rule is to avoid shell script encryption and use better solutions for your problem.

SHC stands for shell script compiler.

Download

Download shc and install it as shown below.

# wget http://www.datsi.fi.upm.es/~frosal/sources/shc-3.8.9.tgz
# tar xvfz shc-3.8.9.tgz
# cd shc-3.8.9
# make

Verify that shc is installed properly.

$ ./shc -v
shc parse(-f): No source file specified

shc Usage: shc [-e date] [-m addr] [-i iopt] [-x cmnd] [-l lopt] [-rvDTCAh] -f script

Create a Sample Shell Script

Create a sample bash shell script that you like to encrypt using shc for testing purpose.

$ vi random.sh
#!/bin/bash

echo -n "How many random numbers do you want to generate? "
read max

for (( start = 1; start <= $max; start++ ))
do
  echo -e $RANDOM
done

$ ./random.sh
How many random numbers do you want to generate? 3
54213
7542
465

Encrypt the Shell Script Using shc

Encrypt the random.sh shell scripting using shc as shown below.

$ ./shc -f random.sh

This will create the following two files:

$ ls -l random.sh*
-rwxrw-r--. 1 ramesh ramesh   149 Mar 27 01:09 random.sh
-rwx-wx--x. 1 ramesh ramesh 11752 Mar 27 01:12 random.sh.x
-rw-rw-r--. 1 ramesh ramesh 10174 Mar 27 01:12 random.sh.x.c
  • random.sh is the original unencrypted shell script
  • random.sh.x is the encrypted shell script in binary format
  • random.sh.x.c is the C source code of the random.sh file. This C source code is compiled to create the above encrypted random.sh.x file. The whole logic behind the shc is to convert the random.sh shell script to random.sh.x.c C program (and of course compile that to generate the random.sh.x executable)
$ file random.sh
random.sh: Bourne-Again shell script text executable

$ file random.sh.x
random.sh.x: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux, stripped

$ file random.sh.x.c
random.sh.x.c: ASCII C program text

Execute the Encrypted Shell Script

Now, let us execute the encrypted shell script to make sure it works as expected.

$ ./random.sh.x
How many random numbers do you want to generate? 3
2189
76234
34678

Please note that the binary itself is still dependent on the shell (the first line provided in the random.sh. i.e /bin/bash) to be available to execute the script.

Specifying Expiration Date

Using shc you can also specify an expiration date. i.e After this expiration date when somebody tries to execute the shell script, they’ll get an error message.

$ ./shc -e 31/12/2014 -f random.sh

In this example, if someone tries to execute the random.sh.x, after 31-Dec-2014, they’ll get a default expiration message as shown below.

$ ./random.sh.x
./random.sh.x: has expired!
Please contact your provider

If you like to specify your own custom expiration message, use -m option (along with -e option as shown below).

$ ./shc -e 31/12/2014 -m "Contact admin@n0where.net for new version of this script" -f random.sh

$ ./random.sh.x
./random.sh.x: has expired!
Contact admin@n0where.net for new version of this script

Create Redistributable Encrypted Shell Scripts

Apart from -e, and -m (for expiration), you can also use the following options:

  • -r will relax security to create a redistributable binary that executes on other systems that runs the same operating system as the one on which it was compiled.
  • -T will allow the created binary files to be traceable using programs like strace, ltrace, etc.
  • -v is for verbose

Typically you might want to use both -r and -T option to create a re-distributable and traceable shell encrypted shell script as shown below.

$ ./shc -v -r -T -f random.sh
shc shll=bash
shc [-i]=-c
shc [-x]=exec '%s' "$@"
shc [-l]=
shc opts=
shc: cc  random.sh.x.c -o random.sh.x
shc: strip random.sh.x
shc: chmod go-r random.sh.x

$ ./random.sh.x
How many random numbers do you want to generate? 3
28954
1410
15234

SSH Encryption and Connection Process


SSH ENCRYPTION AND CONNECTION PROCESS


SSH Encryption and Connection Process

Introduction

SSH, or secure shell, is a secure protocol and the most common way of safely administering remote servers. Using a number of encryption technologies, SSH provides a mechanism for establishing a cryptographically secured connection between two parties, authenticating each side to the other, and passing commands and output back and forth.

Symmetric Encryption, Asymmetric Encryption, and Hashes

In order to secure the transmission of information, SSH employs a number of different types of encryption at various points in the transaction. These include forms of symmetrical encryption, asymmetrical encryption, and hashing.

Symmetrical Encryption

The relationship of the components that encrypt and decrypt data determine whether an encryption scheme is symmetrical or asymmetrical.

Symmetrical encryption is a type of encryption where one key can be used to encrypt messages to the opposite party, and also to decrypt the messages received from the other participant. This means that anyone who holds the key can encrypt and decrypt messages to anyone else holding the key.

This type of encryption scheme is often called “shared secret” encryption, or “secret key” encryption. There is typically only a single key that is used for all operations, or a pair of keys where the relationship is easy to discover and it is trivial to derive the opposite key.

Symmetric keys are used by SSH in order to encrypt the entire connection. Contrary to what some users assume, public/private asymmetrical key pairs that can be created are only used for authentication, not the encrypting the connection. The symmetrical encryption allows even password authentication to be protected against snooping.

The client and server both contribute toward establishing this key, and the resulting secret is never known to outside parties. The secret key is created through a process known as a key exchange algorithm. This exchange results in the server and client both arriving at the same key independently by sharing certain pieces of public data and manipulating them with certain secret data. This process is explained in greater detail later on.

The symmetrical encryption key created by this procedure is session-based and constitutes the actual encryption for the data sent between server and client. Once this is established, the rest of the data must be encrypted with this shared secret. This is done prior to authenticating a client.

SSH can be configured to utilize a variety of different symmetrical cipher systems, including AES, Blowfish, 3DES, CAST128, and Arcfour. The server and client can both decide on a list of their supported ciphers, ordered by preference. The first option from the client’s list that is available on the server is used as the cipher algorithm in both directions.

On Ubuntu 14.04, both the client and the server are defaulted like this: aes128-ctraes192-ctr,aes256-ctrarcfour256arcfour128aes128-gcm@openssh.com,
aes256-gcm@openssh.comchacha20-poly1305@openssh.comaes128-cbcblowfish-cbc,cast128-cbcaes192-cbcaes256-cbcarcfour.

This means that if two Ubuntu 14.04 machines are connecting to each other (without overriding the default ciphers through configuration options), they will always use the aes128-ctr cipher to encrypt their connection.

Asymmetrical Encryption

Asymmetrical encryption is different from symmetrical encryption in that to send data in a single direction, two associated keys are needed. One of these keys is known as the private key, while the other is called the public key.

The public key can be freely shared with any party. It is associated with its paired key, but the private key cannot be derived from the public key. The mathematical relationship between the public key and the private key allows the public key to encrypt messages that can only be decrypted by the private key. This is a one-way ability, meaning that the public key has no ability to decrypt the messages it writes, nor can it decrypt anything the private key may send it.

The private key should be kept entirely secret and should never be shared with another party. This is a key requirement for the public key paradigm to work. The private key is the only component capable of decrypting messages that were encrypted using the associated public key. By virtue of this fact, any entity capable decrypting these messages has demonstrated that they are in control of the private key.

SSH utilizes asymmetric encryption in a few different places. During the initial key exchange process used to set up the symmetrical encryption (used to encrypt the session), asymmetrical encryption is used. In this stage, both parties produce temporary key pairs and exchange the public key in order to produce the shared secret that will be used for symmetrical encryption.

The more well-discussed use of asymmetrical encryption with SSH comes from SSH key-based authentication. SSH key pairs can be used to authenticate a client to a server. The client creates a key pair and then uploads the public key to any remote server it wishes to access. This is placed in a file calledauthorized_keys within the ~/.ssh directory in the user account’s home directory on the remote server.

After the symmetrical encryption is established to secure communications between the server and client, the client must authenticate to be allowed access. The server can use the public key in this file to encrypt a challenge message to the client. If the client can prove that it was able to decrypt this message, it has demonstrated that it owns the associated private key. The server then can set up the environment for the client.

Hashing

Another form of encryption that SSH takes advantage of is cryptographic hashing. Cryptographic hash functions are methods of creating a succinct “signature” or summary of a set of information. Their main distinguishing attributes are that they are never meant to be decrypted, they are virtually impossible to influence predictably, and they are practically unique.

Using the same hashing function and message should produce the same hash; modifying any portion of the data should produce an entirely different hash. A user should not be able to produce the original message from a given hash, but they should be able to tell if a given message produced a given hash.

Given these properties, hashes are mainly used for data integrity purposes and to verify the authenticity of communication. The main use in SSH is with HMAC, or hash-based message authentication codes. These are used to ensure that the received message text is intact and unmodified.

As part of the encryption negotiation, a message authentication code (MAC) algorithm is selected. The algorithm is chosen by working through the client’s list of acceptable MAC choices. The first one out of this list that the server supports will be used.

Each message that is sent after the encryption is negotiated must contain a MAC so that the other party can verify the packet integrity. The MAC is calculated from the symmetrical shared secret, the packet sequence number of the message, and the actual message content.

The MAC itself is sent outside of the symmetrically encrypted area as the final part of the packet. Researchers generally recommend this method of encrypting the data first, and then calculating the MAC.

How Does SSH Work?

You probably already have a basic understanding of how SSH works. The SSH protocol employs a client-server model to authenticate two parties and encrypt the data between them.

The server component listens on a designated port for connections. It is responsible for negotiating the secure connection, authenticating the connecting party, and spawning the correct environment if the credentials are accepted.

The client is responsible for beginning the initial TCP handshake with the server, negotiating the secure connection, verifying that the server’s identity matches previously recorded information, and providing credentials to authenticate.

An SSH session is established in two separate stages. The first is to agree upon and establish encryption to protect future communication. The second stage is to authenticate the user and discover whether access to the server should be granted.

Negotiating Encryption for the Session

When a TCP connection is made by a client, the server responds with the protocol versions it supports. If the client can match one of the acceptable protocol versions, the connection continues. The server also provides its public host key, which the client can use to check whether this was the intended host.

At this point, both parties negotiate a session key using a version of something called the Diffie-Hellman algorithm. This algorithm (and its variants) make it possible for each party to combine their own private data with public data from the other system to arrive at an identical secret session key.

The session key will used to encrypt the entire session. The public and private key pairs used for this part of the procedure are completely separate from the SSH keys used to authenticate a client to the server.

The basis of this procedure for classic Diffie-Hellman is:

  1. Both parties agree on a large prime number, which will serve as a seed value.
  2. Both parties agree on an encryption generator (typically AES), which will be used to manipulate the values in a predefined way.
  3. Independently, each party comes up with another prime number which is kept secret from the other party. This number is used as the private key for this interaction (different than the private SSH key used for authentication).
  4. The generated private key, the encryption generator, and the shared prime number are used to generate a public key that is derived from the private key, but which can be shared with the other party.
  5. Both participants then exchange their generated public keys.
  6. The receiving entity uses their own private key, the other party’s public key, and the original shared prime number to compute a shared secret key. Although this is independently computed by each party, using opposite private and public keys, it will result in the same shared secret key.
  7. The shared secret is then used to encrypt all communication that follows.

The shared secret encryption that is used for the rest of the connection is called binary packet protocol. The above process allows each party to equally participate in generating the shared secret, which does not allow one end to control the secret. It also accomplishes the task of generating an identical shared secret without ever having to send that information over insecure channels.

The generated secret is a symmetric key, meaning that the same key used to encrypt a message can be used to decrypt it on the other side. The purpose of this is to wrap all further communication in an encrypted tunnel that cannot be deciphered by outsiders.

After the session encryption is established, the user authentication stage begins.

Authenticating the User’s Access to the Server

The next stage involves authenticating the user and deciding access. There are a few different methods that can be used for authentication, based on what the server accepts.

The simplest is probably password authentication, in which the server simply prompts the client for the password of the account they are attempting to login with. The password is sent through the negotiated encryption, so it is secure from outside parties.

Even though the password will be encrypted, this method is not generally recommended due to the limitations on the complexity of the password. Automated scripts can break passwords of normal lengths very easily compared to other authentication methods.

The most popular and recommended alternative is the use of SSH key pairs. SSH key pairs are asymmetric keys, meaning that the two associated keys serve different functions.

The public key is used to encrypt data that can only be decrypted with the private key. The public key can be freely shared, because, although it can encrypt for the private key, there is no method of deriving the private key from the public key.

Authentication using SSH key pairs begins after the symmetric encryption has been established as described in the last section. The procedure happens like this:

  1. The client begins by sending an ID for the key pair it would like to authenticate with to the server.
  2. The server check’s the authorized_keys file of the account that the client is attempting to log into for the key ID.
  3. If a public key with matching ID is found in the file, the server generates a random number and uses the public key to encrypt the number.
  4. The server sends the client this encrypted message.
  5. If the client actually has the associated private key, it will be able to decrypt the message using that key, revealing the original number.
  6. The client combines the decrypted number with the shared session key that is being used to encrypt the communication, and calculates the MD5 hash of this value.
  7. The client then sends this MD5 hash back to the server as an answer to the encrypted number message.
  8. The server uses the same shared session key and the original number that it sent to the client to calculate the MD5 value on its own. It compares its own calculation to the one that the client sent back. If these two values match, it proves that the client was in possession of the private key and the client is authenticated.

As you can see, the asymmetry of the keys allows the server to encrypt messages to the client using the public key. The client can then prove that it holds the private key by decrypting the message correctly. The two types of encryption that are used (symmetric shared secret, and asymmetric public-private keys) are each able to leverage their specific strengths in this model.

Encrypting OSSEC mail notifications with GPG


After reading the SecureDrop security audit announced today, I noted that they GPG-encrypt their OSSEC mail to add an extra layer of protection over the incidents that OSSEC finds and sends alerts for. Neat idea, it never occurred to me. Even though my servers use TLS to transmit mail around, and that I run my own mail server, that traffic still has to hop through some public routes, so why not add more encryption.

I looked around for how to do it and discovered this guide by Jeroen Vanderauwera, which accomplishes the task by running OSSEC mail through a Procmail filter which in turn executes a script to GPG-encrypt the message.

That guide was almost perfect for me – thanks! – the only thing I found unnecessary was that he sends the mail to the local ‘root’ user, which he then adds an alias for to route back to the local ‘ossec’ user. Then he filters in procmail on the ‘root’ user part of the To: e-mail header before performing the encryption.

I have a local /etc/aliases alias for ‘root’ already which I use for other purposes. The system sends other mail to root such as rkhunter and so on – I didn’t see a reason to filter all that back through to the ossec user. It seemed easier to me to simply configure OSSEC to e-mail ‘ossec@localhost‘ (instead of root@localhost), which Postfix finds by looking up the local account automatically anyway, and therefore finds the procmail script.

My ossec .procmailrc ends up as:

VERBOSE=yes
MAILDIR=/var/mail/
DEFAULT=$MAILDIR
LOGFILE=/var/log/procmail.log

SUBJECT=`formail -xSubject:`
:0 c
*^To:.*ossec.*
|/var/ossec/sent_encrypted_alarm.sh

And my ossec.conf snippet:

  <global>
<email_notification>yes</email_notification>
<email_to>ossec@localhost</email_to>
<smtp_server>localhost</smtp_server>
</global>

No need for any change to /etc/aliases. Done!

The only downside I see that prevents easy GPG encryption is where an OSSEC installation sends mail to different users/mailing lists based on rule ID. For example, at some of the organisations I consult to, a Dev team might get app-level error notifications, while Ops only get server-related issues. I haven’t spent the time working out how to support these different destinations (and therefore different GPG keys) via procmail.

Advanced GPG Encryption and Privacy Guide


GPG Tutorial

Table of Contents

  • Public Key for Alan Eliasen
  • What is Public-Key Cryptography?
  • What I Use
    • On Android
  • gpg or gpg2 ?
  • Importing A Key
    • Importing from GPG
  • Getting Help
  • Getting Started
  • Generating a Revocation Key
  • Using Stronger Algorithms
  • Procedure for Verification
    • Fingerprint
  • Signing a Key
    • Signing Keys in GPG
  • Publishing your Public Key
    • Manual Exporting
    • Uploading a Public Key via GPG
  • Manually Decrypting
  • Manually Encrypting
    • Encrypting for E-mail
    • Encrypting Files
  • Attachments and PGP/MIME
  • Signing Messages
    • Signing a Plaintext Message
    • Verifying Signatures
    • Detached Signature
    • Proving You Wrote Something but Remaining Temporarily Anonymous
  • Updating Keys
    • Listing your Keys
    • Who Signed My Key?
  • Building a Web of Trust
  • Good Encryption Practices
  • Symmetric Encryption/Decryption
  • Why Public-Key Encryption is Cool
  • Tips and Tricks
    • Verbose Information
    • Requiring Multiple Decrypts
    • Hidden Recipients
    • Encrypting Messages You Can’t Decrypt
      • In GPG
    • Migrating to a New Key
      • Creating Your Own New Key
      • Using Someone Else’s New Public Key
    • Keysigning Party
  • Technical Notes
    • Short Key IDs Are Bad News
    • Finding Your Longer Key ID
    • Key IDs and Hash Algorithms
    • Enigmail, gpg-agent, and Gnome keyring bugs
    • Automating GPG
    • Making a Sandbox / Multiple keyrings
    • Forcing Different Algorithms
    • Protecting your Secret Keys
    • Backing Up Your Secret Key
    • “Creating the perfect GPG keypair”
    • OpenPGP Specification

Public Key for Alan Eliasen

Below is the public encryption key for Alan Eliasen, (eliasen@mindspring.com) in armored OpenPGP format. This lets you write encrypted messages that only I can read!

Note: I have recently upgraded to a stronger 4096-bit RSA key.

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1
Comment: See Alan's GPG guide at https://futureboy.us/pgp.html

mQINBFPOzTUBEADT1kIEMY1Ix+9DyNfGHE9HPjLSI/Ybnsn/bbx8cWmeAktoYjBS
q29mJ0tchjyG8KP38vlkvfNYKn80985a/p7ZKupxOm1dDyAn5TZguDG2fEgCYxcB
FxfMjGKLEFOS6hlPVh/3bm7xEvRuB5P/5Wdch9/UK11qLE3hlDlhnT1zq82Sk4G8
OWnH8BLA8XuRAdwAdri7U2OmNPqCldlmpIsTy68MXJQk7tYi0Rwc55c65U4gGSuY
qw3QzQ6X4TecFO/jUPBnnVb5YcYKxVw75PYF6NnKbbsnDYJoNg8bpEP2SVC0FWNK
2rKYsGsbcco2/ruJuQsThVcuH3l07cAKaSzt+eb5+FWWzsojbSeXwD8yZocfPvEL
eaa0/Jr2220sV6OdSpWBa8mhBI5oTAbD9PDX3C5gyPj78mzDlhytLTCsdtL1Uqgm
DTbIqgDPQBEnGr9Ny2XlIQ6AjuyuahBDl+ElmLnz0jI9bjt0vgAUGjmCCp71aioo
MXZALwVBsdQH3w2BHQ8wU9sYtMlBPBMZz++oIQthmJ+Gb6myvMZCQ34M9TfpIv5i
utAK2xBP/XfBl5BMYl6xNUHOxGhtBj/Pbzcwu/+Sk3mKkC4E2+aUKEjyzs6rDdDs
pT+2B4A1nNXLU1PA+AfabdLnlvm7lMgzr30Waejcz4FbSdwCX8oN9UabBQARAQAB
tCVBbGFuIEVsaWFzZW4gPGVsaWFzZW5AbWluZHNwcmluZy5jb20+iQJBBBMBCAAr
AhsDAh4BAheACgsJDQoIDAcLAwIHFQoJCAsCAwUWAgMBAAIZAQUCVCJ6SwAKCRBf
K0dW7Yc9IyAEEACjB/Kwt7WE5E+GEQ6DFVqFGGZpKQaNKI1bLi+xD63+gXuQzu2B
2ujlerjKdiNaI7D2n0fcFOuEouxaRUkizb2/hV9rqAOGqUOwnRBr31wVqQP/s2xU
4MMev46jFecI2FHALpNXA6/mqBh4ODyfpEetxM+DiaN4vUdiiLEtOfjCVggnCS7H
+JirccN7MZzt16P7AEbCD9qZwc+Gnob8DbXKm6VbN3sRG00c3zUjL7VLGC+qctWw
P2HRKC1/XXxX4Vjidbs+2+ygAxlyLGVB12L2PTA63tR2ppJoRWAh9iLtaK2/uszH
h9Gt5EtL4d00rqVhWHtDlPAvjyBAyomTWPysuuwJvob+nR6cSYobsi2/H8rj0F1l
zuh0YLCt52dZ9SqiOgA2SCUDa3opO9ECUYbgVABiwpSgj7GP9UTOIoT7gAZlxlEI
s9kdkDb2I7y4xkImm0nH5EqAGP9Qt8Sc3Dai0iFK0+k4o4uY1VJD0SZlm2WxjLpJ
Zc+CbwGEn0pN5r+g6XsS8bj26l0Lg3ixvLlmiwsDnP2gVoW1/cGYPq+wMf7++Gms
wbLhKhN+HSNSbE/thKkxQ14omuhP73kJIrIIHyQr0Z/KSnBDluQoBHWTnQ5SZ6EO
bQi9zRGZWhbOyiuF2jnTwoD6glOnOao8viNqKTVH9ItHQywGEcYnC+ztu4hGBBAR
AgAGBQJTzuGrAAoJEOSBhLWwVnaxj7EAoMxh7ycVIU2xEee0kkNzif299NXvAKCp
FntsiNcSu34mmQeGhikf10LapokCHAQQAQIABgUCU91SFQAKCRCkgk4/+RzmWWbq
EACMs+Hq0UulmnXPfTNPJPZbZprPRvWRGSmIr6GPtuX17IP2nDXsD62+Ls6Vitnb
laZmfRXwc8M5kggU5n4G7t8VJj4onaoIJv3jNrrJgUwsZsSij9mQdoRxGsjNmhBb
1l3ujsJ4TNvjTc8XxnjtNbSpq94tfg2QvsdCdctjaQjzKzp82sB+/miKMFZDCy0L
EF2yKTCebnUWy8F0K0W+GpVaWxrJzfBkmY1772Ruy3ovnIkHApyXB0buTws0u4HN
LEJgzJgtmMrtGXL+/ULpGDjjKYyhrGw7ciDvWZ5SuTS5W2N7Fpgn9nfXQWy4zgqv
eq8iNZbnT5Bh5hB/lNFLUAiiH+9lh9OpD4noSq9MumTdRlvZTGZVnPDQRipF++J/
5g0nEq3nEAAIjTHYnmzP7T83Rgfq1+jwjTTD6r6W1KauRdBInbNlNQZeklqLyvwZ
qY7QtzA58+tPcyIiwP8gsTF7MR/ZD1/8Zh5OhpbeCIntXs7s+784pfY/Cfd1fwp9
cr7eLQ3BGKTAj06mm3JOFokpU0byjJFADaePe6LRE6Iy5yBL025fIG7yPvTV0mvA
SnJERwCFGPAvEOq38V+cXdKxSJBbTt7l/7Ma5M18b/c5z9Ni18BD6iOj+zGuvDA0
/QhAYzgkjvYLC1oEqt3OgwITyapf8twVt3rcZN+/gk2TU4kCPgQTAQIAKAIbAwIe
AQIXgAUCU87N3woLCQ0KCAwHCwMCBxUKCQgLAgMFFgIDAQAACgkQXytHVu2HPSMh
5w//fnhk1fU8LUmmnw8qKlIi0l9zAcCep6eYwomJSHqugDLWkP4nXprbufrCXE+l
x/nZGcHfnvC2X0+d+pZgufd44TRHTbPNGMe6tL7b9FAhn/sZOMtepXYz0KmDehdy
es+/+1KN6Ihen99GieWKcc09nVBoQG0DUlCD2SzC2x4O/fsgzMvHYyLJr8+jfhs1
ZBBY8NMBejOOk6NKe7asLuxTJFDyb/6B2XX1uN/0AJWomIwz4zh8FsKhG2zk6VuI
aMcG5hjpzPp7mT/H3BnP/9Rb7q8Jd+yuG4O9mENzz2/2zB1x8WRkF1sNioj7fY53
gDK09vvdjGfJJPLYsHNz7/pPcDlm5J9Nc8Ngp9XDtSG/xBnJwlFTHFYOHCQV+htO
xMt+xEL5vURnDa0aCrganDm444NUtQAcXtVpvoHhUpHBtdJna6jz9pWDEsUu28iZ
/czPKEgsK+V4IGqh7jLsc97BcOa1PJ0AFpowuKzRCdMLlNhY7DxxeSpmwBylLqd9
I5BN9PEo7Xb8+vmKGRBzhcqLTnMZVMJp2KLOkvgjt7uXrlSlyfO9fot1nQNBW+cM
+EeVN0hPEYHacymNdCDem8AkoBlH5SofYSqZE+Wi2NRHFCts7pjMJmifXCDLMSNo
g5gGtV6W6H+4dijTiH6xs959VKx5wGRKl+js37SqfPuVroCJAhwEEAECAAYFAlPg
oqAACgkQ4xY9x2rQWw6F+w/9Ej1CCsR4XeM40hURsKo7b/ZsMpV1MoQ2+7cewBw3
nWHYEUaWfiKvo1nbluXbnt2oPyxQPgJToJfrlgSF2xD873zHhBOaAqPQexPCCFYP
9YIBiuBrzGXEBIIUd/y/TU65qkiAD4YdeNGaCw5DfV9BzzffoQrHPAe/YHo3JB7v
nSN0xy1FBtEoPPyFS0YN4foFC0LwEiyKd3SwkWtkTbvkjgTiXN1A8fx5w8oVPHou
QIpzOkzgAbsupCJGPsCyJNK50f5SyRqSYqeE2NuseAPjtdUf/1aI+ahmJ/yNZLq8
N9AR+OfqGVL7djOMifJUxOwpIvTqhBD/P7Es7P+i2vCOA0ww4wh9o1vmzPyfY9LW
tq+xH3scd0bU4tEV3CXPwl3Shv3K9y4ezdelK9eHOIt0Fno6M0dgAEQpiZGiVPBm
SDN5SDiUMOZ/2eo86vccoj9YN60lsMypJHwqvfIyXiKpqIz4amgxIUWOLWSSdSk8
BK8UnsmnQRYUS0x6/gHS1EOrB5krXtVWgt1xJr01wmCEDb982kva0rBVhVrDHSYC
CrOf7G4BwZ2weyGE0kMXbAeaunuK49y6hJEoZCYS+KGnHWhr6eyqRB/oDcnDvbNv
APtJrtMV3IpW7Kf5JtSlYDVyail7yMb+dNZumznueQJ5DkC+q4Y+Nfez0dGfbfj/
eVKJAhwEEAECAAYFAlPpRKcACgkQrUNxyt5zEFBu+Q//TTikjaqqEAD++vQxyq70
AU3Xx9sWX/mrMLbVipCIhCZf7A2IHGNaEzyN1dzT6yIX6mmtRsnYRuCwFRs+nv3h
2IkYe3dyOe6jvKBtSs/st2OqGt7WDn877L/h3EC7sLAxMHMHr6mWv3nJKdmCwoDz
lRU6j5P9KPH+sNcSjKFAYTiUHhMt5cKo8QkQNPzySCvyOEr2NVwSh9YuvVP/irRJ
q3p6ckSOPUBptaSCA/jqMdYqKXDmstf1IRfVqHN8mqA3N4hZ6xRDiq3vbXXxGQwv
LR1ZvUD4sUH0Y8u4lRluYPDilqknxgaBC8LtkTHYvtlEYahRSwx3h5IjIcNdUhM1
EyDYsR3NcSoirBcKgqNILEl1ohmpbGdENJPfp4h8VDu+htE2RtflCdHRFXIx4E5X
1MIt1m71+cznrOKW4jbQ+ecIFk3Y+tnJVNVh67O7I3XT0x2tdMTDuVb/jNcd96di
+9mp2XgNnMKw5OG9bN47y/x3dgVk/w2x/lun9PEkyocptXX1OB06LB5GlIPi1VIS
DLO5lUImj+GV1nrAMsSVRkNlY0bOEAHc745yPbggTqdlZAPa1fQbrR9Y/Y2xiBky
cKyXhfQF7vnFFT8h8jqkT+Ry1S712K3lAF6AqXEexAA1lRvFEfyrfXBEDCNPPLQ/
AObahDixWncHDGIyWtLEqdmJBBwEEAECAAYFAlPpt1kACgkQ0L9qe/cpGAlMziAA
yLZlWEfaRUBxXCqR1IkNluZae6kYAugYubLIJI5jca3r7SB32tdPBxgZ6X+P+4KU
rbZv0Rfoz1hfswXK8isgexTMY1BQCfmIWNwmPZqTI9ozeXQR+qP90Cm/wluA9b5D
UUH29o/23hlcu3C/7YMdR6NElJgaxSieAY/bsjfrz/NOkZdFql5ySVJRHL6JozDf
Fmvm6bS6hBdXMLILDMA8KKDfx0EW2AUVW/4kw2wKQEgOYPUfhmi5wkcB53BXimtk
DS83EkeiImeVZekLgw1NSr8uowH6A059wC1I7zRjXF+i6m/2nmvY56uEVKW3d34G
etKkwfZYqqzYBatOlbM+TZ0N7AC2om+Kg3OEDhrKkkCgh4FfACDD51svKKWTrHvG
fVgOB0iZiba4+ItcNrlLWTrDHjPNOuWL7CAzpDgNEYS5+n6ZAeRSg71ToDlJUC5q
Vp4jB+polO6iyqOswsxerEKLJM6vPvl/IyOpcpBFsG0PlR1S5QKc1ngY+xPLLVA5
e+yZ4GGHmGp6La94QAE/2baW4avS7gkgzIkkWKHw1zfI2zEtDDiO59pXtaT6rLO9
GuOhwgQmdtmIzmj3tIfFvRDmExKy8pHlupYgl8SThomkjrrb6vos550P23XRWWBh
qOqHUI+P9eB/yIvg4Gb36lrgjsHnY6wfZEC7Jm1pwqt0Ly1+PdMI1IEDeJERGTJJ
owtchT7r5WFsW+VKcOedVt8YLceeYajTnMUWk9v9f2uSppX4yPGncg7wdN331qLa
udXdw329+9UJY8BoXHsypC82WYgBApMk4Mwd0/mTRkXEIJzWef8y5mH/VKed9HIo
j72RLN+Iv2gaZenn2DjfH+F3BIOMrSgQqvFabOGbuITUqp7Xldgz7OcL6WqgpRjO
RFOtym9n405ianjwO3U4a1Rt3br+eFrROJQE655CL2UTOArI5p7jL4XRSIwM5P1a
8F8f/fSnHLuADAkth+m17VQG7dQLJ3kpjuDDgwZkQnNlbpCFdpVk4+Xtxc/Yhxpa
0B3JxOtngYcBMMxloyB57yNkvv73gfRKgclc/UNw7hQWYbnoQDlBMxdvnlPKFiQJ
g56j06rq7ZxRiadVpb0smxqP7WDCztIx3d22pF4GRSr/iRgfwZjlG4iUzDaXn4Jz
H5/7jE/RAJcGupaJLSDsRjuEvwd2LhTVza6EyPk7HDFKN537F4mtp5LtGTS0ySQs
1comUzRRlVS7EgqbIZxYZ0k9sfHPlNS1obuRi+X5Emku6Le2wRzliWWjkgYFEFkm
D0PhGuZjzjkTFavkJsOz3vuYXB/GrXOgKvIXYoTWY3mYPhoL87vlFCwzsdsgfYXh
FBsEfx+danfwjojhI/ea6YkBHAQSAQIABgUCU+sBQgAKCRBictNXt1RfXrptCACA
nPGcWLfdfcvkbRlE7Yjbw8NGvvJnImZvfWjb5lRaJhOVpxZZ+e77JDle9vezn2cZ
JTABikhmI9BMGN9WCYBEETY5SJ0PxaOuptWa1rQUYK1wAoReB6dgT8mG9PODubSU
rqt4lQBNIH+7F87nyESnGNUS7GgRHh2656NFnu1TJ/EId0BZIEc35Eifof6AnyLn
5lvcD25bzwrMhZqQUYKD6vkom48AJYBto0LlKJpAkA0b1CWHvtmaxaBQyKFvs8tT
dA6kvRGhc3scxQVauNGJxNLIqZ2++mhhdW3trA0iG81+L6iXEiIy/XFqfcj5LNh8
PsJfNt9mtEHF+zK2UlN3iQEcBBMBAgAGBQJT6/NfAAoJEF1pxx6cpVoXb+sIAMJ3
cUa7JXYgNbRaO2I2tQKuNN+KjSJ6mrXrurLq1UCMjFoH3hInX2kfVS35aeGpa1yH
mJInS9Dvl4yW+ZPnpiOtvddFWsomxYYDt3LjWda3sF3iTH+DpKuhpQV6SxNWjWQn
ygih1BHfSnKV9sieiMziV/U57cr4VeulPLOp5D7aaKZRqoHvoWPk8NfGQf0xM+YM
yo9nSG2EbDxwqRvh9aZ34m7rwKefTrECosfb+/N1uFDSYwRzadaBZCXsrd8/dKpQ
XjE9XnTbpil4I8DaEKJxBlrmq7F599eIdZaKyqeCk42pqQRtZrrM4YjoU1r0uhmQ
AQN6kCOFxb2i/wKcs4CJAiIEEwEKAAwFAlPswA4FgweGH4AACgkQ1jWx3VA74q1F
dw/+JNL/i8M93/eQK5WviFcBR2j29/Gql/dX899ZBBQsWSUjv3n5JiTi0SsUpfb0
rPVNhy68Gyv5OAHe8rXHxJvbheKRN1zYV1JEM2/JZHowgOE3/XhKQH+moTOhRRG8
luLu+a6+edix+jLFLyAPvkC7HzF7wJsoeUKxoAlIcoSdORnWaambFyWD21wzlvj0
Mhsh1LOEra9PI36iXiC9UwpAvsqeL6ucHWIBnKCS0IDK2oZ/I51qX+6JmfBIYh4s
v6ciyUdoI7n9h1L/7bb1rY5X/BX/xSNHIrcTKKdvDmoD4TBGndsevq0uF4gTtAid
9G8l9nqDKKEzoKLB/V9HWqh7DiUo0yXAGWnOPnVTqwu1v+3Shr7/eE+cNRW+lC+z
CFwmOsZu0EpIQ//Y46x7Z6MP4aRirZVbZp6/s6W9gcvosOi+6Cdv+ESh2sA53TgY
xv4nR0wYNAbK21lyJCnP4gSJTjjV7SAXQ3sxoSUZvuMrUPTwV/4QephyolVGrhHW
/CDSg/GT2G2rgOQflx6PncbgMZyOKtXG+6FSNNQh/qdo4azGUZyPo2lVH8NwVOzb
w4m20BUlmdWPAB3We9zWjEDg2oXie+Q/tvjiZqAZ7XuHVSJmfO98fxWh5juW+KKt
2A7b+JkQoe93ABBIMjauT/HN0uttvHA640R1R4BgvgRfAI+JAhwEEgECAAYFAlPu
vzAACgkQZhiaXqIZinylwg//UVk7dpUsDeONsVdV7NoAgdk0aBqLi9in2isM4LZo
irH5YJ9GDuQdZQ8dI8ZMz92E/u2+iN4CX1aa2u1HW4Lm0BbUXwu73Qxc4d3v1X5D
AvXWSQreH0NDReV2J7pvpGqL8jJXf4Ob0X19rh+DfxuEIgXwYFehVOG7JWGNhI5y
itZOlfCBH7QN2V6XuaEay5NSWko4N2K91dcCiMgoN71Ya/V6/oSE2OmJWY26DljY
CI47e7yYEn81qpO23vWiWxM0ZXFPDrdBt7niLrQZzr6glLMl3jULj4y8ySDm4r3U
r99B2bYt8Eyp0Inr+iub3iBuVV9O4Ri67rbZzW+Wpy2VftI6piTFDr1p8GHcUpZu
wbRlVh7reAVoHXIxVAmB9VfXk3IR3XZynn7Y2Dq0YchNbQMm8FYTm7xTWJ141/SO
92GYz0k+roF2hiDYlVfLG7lgy6hbDTOw3lT3FctIE+p6V9GJ1DfPR/iUCYREid9y
rFmTHKEnGAUduuA36UtZRwvUFgE79xf5UEOklkF1B0wdy0WCPXBVyt156FFtJH6/
inmwn/pQ/e+402I53h5r07SG4aGtROOJEzgUZXZSaSuc0+t2wFgtCgUgf1uN6igf
lPzRk8NrQUE/wrUte1WmQWrd5vN05mmQ0iBUpR723RMP8rQuSBbcM778Uli+Lwrs
dnSJAhwEEAECAAYFAlPvp5cACgkQb01eanorTvtGCQ//e5uJk3KvRoivoqhZ1p5D
QUoZTDnGWf7JYNMptSvHsgGQr2DzxcSJ5e9oTMPuSRwVAqbhguV0noffArJxP0DH
zVLulQs59znWNz+S4R9MThhHE9pcHWI+lqlterXeHfb4DpuNWW3Tq4zkoaJSLMwi
20ehpITHZ2TJy1rkwETYljMkNgBTgh4Xsa0CCVqM01D++anivAJ1u0+SpBysSeo0
lqvoMD2N9B5he0ZJzoDE/svziGwJXcEo5HTJdWrXpo2NW+GRToLQQTHeEVxGMgzn
YdsQF6IRmiQnCcEzW5kvneyMeSYzbIOmuhTaA9eTJTMf21ll0rKCHzGimlIrvR74
Cnku78ozGZlM4/kRygigFpAqaXJ6kzMQs5BYcoCL+XbIy4Q/m7JQjJlpPYuRdVm+
aHgxXnm8QE72lWBrXMEQcj5wd0TF6zeoP1NoKSrlS30IX+k0doS5b3TV+meyL2ky
Zk/v4G9Bvp53HYLvlcPfc7tnC7GcdnPFzDqUOG/iAd3oEYOARBuPKsbwtt0PbwJD
rDp85R5dqJnBxtHwy+GhvxsUaQwlSFCWcR8CzIjQtxBy2I+KhFJeBrOr1REcIDjg
CFVsrY6qnL2/ko7aqg8L1gtM4MhZB2Rgn5lldYBeqPrG9l13a5sXDpDOahq8IrXD
bRVV2co/gkyHAcDyeYoOraSJAhwEEAECAAYFAlPvqrUACgkQvFIAITmUIb7CTA/+
IbFIoFyOY2zygljCeNc0R8GhLHYyVRyRYGSWXzZr1xafNTev0Uzn3OlQBgyWQFnw
RU6tFzMy1kPgrVecSd+M4GlYf3UbWL87PbdhnqbQlbhmT6+3zjP7haHYDtwlEmEp
v9xEOsiQ3/sMY8E9ymfTUGa/ijgmJdv/3oD17EKlxSfNjGQBl8Sd0bAeCvSTd0UI
sUJsn1onc9MTYkg+jMByugzM9X5fk0wqPnezLzNO9RYwL5MWdkHm9rZH3oQt+/kn
sCoTmYa3vTF6IPdJJA4wKFhyW8I/Q3ZtuI3G/rpSzfkyBnKsL7EFCsdUVCLBqa36
/oGtH/Ij4Y0VlJNl2fcSIg6ybroF62W1X0d57Vgrpks1nKnb7wQg2kmNN4nQ0tdd
V1P7Cvxl0of+Uoa5xkTp21gWn9aTdAzwleR+V20eSdOcY7hK0MTsgO9ew5mmFlTr
BcKRUYU7OqqwuOG5aGotcj8DCgITDDtAEuKe4ZSRVyod4uj2+2oNnMs6SuLz3t0B
V2aj934wGweJc+Ol34Et1UgpnYKCqdSlnZYVb0VXxb6WAJOK3du7U0F0MuBQ1PEu
0jFUQXeCKeicuoR5fkDPv73vxnKbz4iLK4cqM5mKObkCX++ack1xXeZcPZKfxjrC
pecX9NW4qn8iB+/btU5h6mtgG8w0AdOLj8Rw+P9OQBuJAiIEEwEKAAwFAlQGmy4F
gweGH4AACgkQF15PwqXDsY3Ffg/8CTqwvw1r6XFV6bYQ0HL3K1Buwu9oW6m9Cckm
q0OvwMzQIkL2AAzpbn1+V9piew80Cz6apA5yPsyixHUJM8UDB/D2KXUfUxx9JZCo
MdF4eaV+p7BAe7Oza6ZgpWZyxdHmOnu+/ivj+yZwDM0a0FZQyUwmTHMbylq9CTH/
3E4b1qyE0v/OI8EgMNn+wIggENm006spCsTUN8NGcA8EBrTpRX+uxQWo2Jv768QP
4g+edJpG0wObAxt0Qxx+AOyHBTwQYB099kCWVcfOF1pyWtHlYa3ZPRFco7KW7QAd
aB4c9K1bMAKbn0Ayzay9ySmtvks2c2Qrw5aDQPnIWJYx7VjTlQ+/7fwap+lBYBRt
RaO7JuSZIkGbh+N4oj3xoOxtct5pSPPvIZfzxwXryl31QkNSCMFrR+QMm3h4ZqYS
VUz34qnl1OPC5XwZJXiHzS8O3BmOWUzd2aiBxcAx+6LYeFmoS++eZy9GBzjl5004
IchYXvGn4ugmAC0ij1FjBslC6sZ4QX2gMHZ3+IgRGuvlPmu8lCo2GnplryaOU61Y
pHDhNMlpx24Gazj3G7LwbPU/6yufioKh6QzlVqYqcSr/H8cCc11ZmJkoFFq7apzx
6PPfebd1HqlgpqCgzJehY0Hbw/i73EeavXZhSTcAichJfWweBE+cISqpuM4f3M9+
7z7oYlCJBBwEEgEKAAYFAlQZtkkACgkQH/M+0LxxvETE9SAAjKxVDGAZ1F8ZQ9pT
8AWDUBXpqtBBd4PiEmi45/edLr7ukuH5yn0AAalAjsumJNzH0sVnEySxGaaq/r7p
VLNAmodOYNpmZhkKnkuXMPKyE8NiH8ajZ3xFSmpe6UdhJEa9RjsKgZYuoEV+oHPo
3h10d178GOimTYFAG1AxHYZVkYGlwtpNakAO1UGTKYeM0Kg0av4o7aBK+vNGDgQs
Xr8+9dK/8JbtfzZQ3RiAIZQYUF7KOf20/7hJwdRtigZJ7qkU04jwk/FBhMk1wsPf
qi+qLzr3Xs7L0vAdqyR2sddyZgK/yLEZXwVo25vex+9+3Kk33u6g5eA76Q6IRazp
UNeO/WCQcAmLZ94ABF35zHEKlMFIa7FeUzeFW3ZfxQY8bkUy4JvA0uxYPR5iDPxK
apKU9vcjKdKSFD0mHbAPOiX+pyAkm70eVNXxG0HdAXxDDTfMOS8x7YYvPLr1ubkU
ogBm01V2HS8O6NhwVUgREV6h5g3At2ZQDsvdues9YhvaWfOunP3PliWybzAPvhcz
GQdkj9adupu85u/u+MjnZzsG9/ITQ60S5Wg4KtL85UKY6Z2djDy7JZzuSStmt6Zv
fkfndM2ZKKj+ZsgLIyyFxZk5pZZTCsxHniquSpXGMeQCVBjbQNp4p8RW0/kLFLIk
kfMhF7StdJYJb/LUI6N4UocPq2w1XnD8W+NrzFtDL8Jg1awRg3c3fJrJzTJUCyJe
zkvrvk5Z+GeHwa6YFk8kN6dNmBdZ2clBImD9GsOPBdrBFlPTh54lwgskudD9gNM4
GdS0EMrFgL8wOOIbAh7nNi3PE23kaZB8LNERETon2q/vG7a25NMjIZet53zqqe1x
qxBiMG6l0u45aadTr5+DFB8pIZArwbHjNZ3k6UbYEzJIdWR8lkSks54lHLvYV1Q0
X9fuBI4Q4mdjBajLwPQpiVmSDkZJckdTkecV+3DOBlylqS7sogKv0Gjva5ls7ghs
cKJF7/cAcbWfAIN673TEGBvF//AgmB4yXG1JnlUfLbtLvGktasQ0P/sujX8tMl7n
A7Q9h5k/TkUSInZkKuWUovrJSGB0zsdJJdpiv6okgeNPnd8+TnFTubfcCfFSnUa1
gbFqyqvuMVmzNabh3vVPpCFWGCeCYsMon+jPbWcshY+mESVjOM0c5MP/ny3R4d6Q
ULibMXCKSkZCDnPlnSH4us+LrAzLRtgw6/e7frnUC/xTd/03IvIM6H0AnFgIv6os
/pAXmLEbcCznsqykgBDJgkRdscan4UfrHCR4B1noMxqOJSX00koVG6GeJEQpWns8
hJIvqciT5XUmMInxN1+aPYEWFXJnKmmp49zUCm6nKf4K/Z9vO1Dy9uwLAYq/GG7G
xVLD5IkCQQQTAQgAKwIbAwIeAQIXgAoLCQ0KCAwHCwMCBxUKCQgLAgMFFgIDAQAF
AlPc0vsCGQEACgkQXytHVu2HPSOB3g/8DNB8UYeB/btVQ+JjOIqOdjtmktyZjjSU
p0WLXYQ07ZGX5SghkaBjUEC/nCa/cyREsvvo/B8iYSneZJehU00n3PIb8MEwnCOL
BvMWYm6cw93kf+hMtjT3DKoIOpUc+LOve8f900k90K7IqIZIX227L4fD/bQPWxdA
4QYv4pwk9PeY7uHQYuPnQ7QSG1r8RFGX5ubtiC+lZb+P3Gh9BeOAIK4eGPeQjhKZ
Yx/A2mH9+qbKWyWSS9Quw6ooR0lAzVU0k/bGx1Oj6AWxO02zt1pjauAUWJRYky2V
/aQc2gad41oVeAJ2fkpU5n/paxJyAkFPXkUA9j2bIoVH07YaVvTGH+kBuxgTZCQv
UA7ntb8ZIQAXbaOHX+lDJAfiIzfCgjvn2Y4MmMl1NWnYtQYmIOJzk1JvHpfKC54B
cA6k+hZh7S0WKBTb6qVcHKi81xortF5uuVpeSvPhlUrJ1FQgIysrtsT3bPS1Hh0Y
gVthHC05GzDj3Ij0ry7/QISYtxiq0Z5waAaeNngPlB9zaKste9yKyREm0UHo0bY0
k4K3Ywzj9Rzs2S/YdZrfb2WAIohvi+evsEafLzrZEt78CecRpHfJyhv7BI4vnhB+
3frR6LaEbdkX5blF3MdsXec2wwPolA48vsGin0/RyUKoIJ3QVvBPwJmc7D0auWMA
NE5rfb94NUSJARwEEAECAAYFAlRgzN0ACgkQPogg/4XFQdmIMgf+KWkhiWZZVi+K
IyxJoJewniHVd2tnwUB6AeFPXrkc58jkLX+7alQY+CrTFYcZ4ojK5Xv70kX3BUZI
Z2hzcy/d13OXPpaLorM5ngcjLhURGjL10/1Rlq8S+jWJzQ2eCv2PtGfbF23dWhKp
fyX+V7kO1DRATu6xlmrGD1cY5zFpEMCiC96ZweK1jztN0kFOpjEQqC5RQOwwMsTZ
0rpWZ2TNtdiH2u2SS0+cAr0KP1Tm1HeKQcnUtFDlQd+GFTDO1ofRqbNTy4PQeq+s
i1IWGSfRatfR8yW0hE90NEn+09sW75RHtEOL5Kavyh4Io2Ms43Sna3Buv3Nnh6HH
uGj4IKMy07kCDQRTzs01ARAA8jMbb8iyvIQJPjYg96ifkwNd1UsqWQqbjgmxHQ93
b27FWzJEr9DrTxFnlHE1Xp/7XbRD83xpVzBhr/0O758HmM14oJFu5pyao4y2xJMz
/Y4CSmi650kixhrJefZz7vZ4SEEo2xMbLPnFwQG1h6L3ixw6UYUGuF+YZ42ClDln
TshR8npeWax4x+wnWFK3rsfKXMh442IJFIExLhzWlS8amj/Ir6kQUSeRNdry5CRh
wPdFwVl9Tj/Nf/H+keMdvar43KzgFNJ/DHh8yshIQBB96ja763gXXH5wJ/mf7CCh
dbgZqKXU9RD0t+zumvb+jGTgSrIfdI/D6Lc4r+iC4N1aXhaleH2PUC5vMN1Vxvnr
UPPFU1O7O4jZjX3SRPiprmkwqjzfiPYhgLOGT+ejWjOjYuuKBXH7YNzYMc7HUV6p
3BHEylgCmJ96yRzxNDouI1PAgVatu4/d5ZFFj6ibtqObo4UAZQ+8At4Ys5zOjxHX
Fst7CtodUWotl8B6ZWv5yHW07qGZ0xdRpwduHWj7mqAUEot+2YLMGry2fSdCbpcg
uTWIvKQQnF0tQq8sEuuVpQ2MNosm3hm+u0kajzjltwP/W0TVg96Rt03mZ3IAdYcl
VPgoxHIVKOa+pNQLmC0eZk1dZ3X9EFr1D5M3CSdG8VH7HZqKk4N3dzpQ3oBoAkmK
or8AEQEAAYkCHwQYAQIACQUCU87NNQIbDAAKCRBfK0dW7Yc9I8aiD/9YS+IgcZla
HVrN/H7sewqyNEUa5T4wz6F3QvT44+QxJBKCW/NQuUrnqv7hn2DImXMXeG8/99WP
KM3tHf0mxq2/uLOMqi92SzuSP2Qefbp3P/VviaBzqkIEIQWGCczQ//Dg8sWX/UbA
xhZ5he/PESjRx0PmWSsPvhGOisxcZV7BVmmpICd9W6l6i55oHWXnpVivVBmAK3+X
InQ4ybCJ0+jAZ5FlOmoGuwq1OXX0h97P0h4Hzb3u7jEwdkVsSx4BvtlIwld9+alC
0izsCC6fCHpjrK31nTffFJ/PhvojLGiRla6f7qNKFRHabY7U0ldYMfSgsGInICTv
t2py2SdBWQh+SO/K3Y6Pb96Y/tDQUHLay31dmXCoTslcebseZCW+WPOGKehlBFWd
hDGuP/2HqJbU/HG1k8OKIqPYIFVFbtzX0rzuq7M4pRlJ1fSg08QMTOQjhfrbm46G
NT2xwaAIpHnDBD7BC7R+xrY60wiEqqAPISJsUDJFK7cRQjZV0L7+k9+IjspuzYYv
Xr2mKKIAojUE/KLxbd6KuXIk07P+vKse66oC8XVpbn6ckMypftidYyyyH5jej2NP
0FuP9jjl8eYgSZl9tqaU6Y9vDyXzE0h6F4SUPiBx3hEIrVzFJym0d6/t562bstQO
pIPGkZxLOFm59msUf9mBqw7rJEs/EqhQ2w==
=7DhM
-----END PGP PUBLIC KEY BLOCK-----
Fingerprint: EC2392F2EDE74488680DA3CF5F2B4756ED873D23
Long Key ID: 5F2B4756ED873D23
Short Key ID: ED873D23

(Did you notice that the long and short key IDs (of any key) are just the last 16 or 8 digits of its fingerprint respectively? I didn’t know that for a long time, but it’s obvious when displayed this way.)

What is Public-Key Cryptography?

In short, public-key cryptography solves the age-old problem “how do I communicate with someone securely without somehow exchanging a secret password first?” Exchanging a shared password securely is a hard problem. You may have no way to do so if your communications are monitored.

With public-key encryption, instead of sharing a password, each party generates a “keypair” consisting of a “public” key and a “secret/private” key. Each party can then publish their “public” key to the world or send it directly to the other party, while keeping their secret key private and safe.

If you have Person B’s public key, you can do a few things with it:

  • Encrypt a message that only that Person B can decrypt. (They need their secret key to decrypt it.)
  • Validate that Person B signed a message with their secret key. This also lets you verify strongly that the message was not corrupted nor modified in transmission.

With your secret key, you can do a few things:

  • Decrypt messages encrypted with your public key.
  • Sign messages that others can verify came from you (they need your public key to verify the signature.)

What I Use

I accept and transmit all messages using the OpenPGP format, which is an open standard, (RFC 4880) and the most widely used standard for public encryption, so communication should work with any OpenPGP-compatible program.

For encryption and signing of e-mail (on Windows, Linux, and Mac) you can use a combination of:

The Gnu Privacy Guard FAQ lists some of the other e-mail programs compatible with GPG. Note that you can use any e-mail program (that doesn’t corrupt messages) along with the gpg executable on the command-line.

For Macintosh, you can obtain GPG from the GPGTools website. (I haven’t personally used these, but others have recommended them.)

Alternately, I sometimes use the pgg package in Emacs/XEmacs which is a wrapper around the gpg executable’s functions. You can do something like highlight a region and do: M-x pgg-encrypt-region and encrypt directly within your documents.

For encrypting files, or doing anything more interesting, I just use the gpg program on the command-line. If you’re security-paranoid, the fewer executables, the better. Most of this document teaches you the fun and important things you can do with the gpg program to be secure.

On Android

On Android, you may want to experiment with R2Mail2. I haven’t used it and can’t vouch for it. There is also Android Privacy Guard (APG), which integrates with theK-9 Mail program, but I do not vouch for it. APG was not updated for a few years, but has seen activity more recently.

gpg or gpg2 ?

GPG version 2 may be on your system with the executable name gpg2 . Either executable can be used for these demonstrations. Both are very compatible with each other. (If you want to know a million different opinions on which you should be using, do a web search.) Version 1 is more tested, and is usually a single monolithic executable. Version 2 is compiled with crypto libraries like libgcrypt externally linked, and is designed to work better with external password entry tools. That is, gpg2 is designed for graphical environments, while gpg works better for automated and command-line use. From the command-line, I use version 1.

Importing A Key

Importing From GPG

If your e-mail client doesn’t allow automatic import of keys from an e-mail message, you will need to save the plaintext file listed above key to a file, then import the key manually. From GNU Privacy Guard, this is:

gpg --import [filename]

My key is available from pgp.mit.edu (all the major keyservers mirror each other, so you could probably get it from the keyserver of your choice, but this one seems to be pretty reliable.)

You can browse the keys available on keyservers at pgp.mit.edu or the often-slow sks-keyservers.net. Who do you know who has a posted public key?

From GNU Privacy Guard, you could import my key using the following (but read on to be more secure.)

gpg --keyserver pgp.mit.edu --search-keys eliasen@mindspring.com

Note that in all of these examples, whenever you see an e-mail address, you can usually substitute part of a name or part of an e-mail address, or a key ID. Most of these commands perform a substring search.

Or, even more directly, my full key fingerprint is EC2392F2EDE74488680DA3CF5F2B4756ED873D23, (it’s more common but less secure to use the last 16 or 8 characters of a key, so ED873D23 will work too. (Note that the shorter key IDs are just the last 16 or 8 characters of the fingerprint!) Read the technical note on Short Key IDs below for interesting attack ideas using short keys.) The following gpg command will import my key from a keyserver, using my full fingerprint (you can also use the last 8 or 16 hexadecimal digits of the fingerprint as the short or long key IDs.)

gpg --keyserver pgp.mit.edu --recv-keys EC2392F2EDE74488680DA3CF5F2B4756ED873D23

Read on, though, and see why just importing some key off a keyserver isn’t enough to be sure that you’re talking with me.

You may not have to specify a keyserver in the lines above. Later versions of GPG have a more reliable keyserver list built in.

sks-keyservers.net monitors the status of keyservers in real-time. (But it’s often down.) If you’re having trouble importing signatures from a specific keyserver, or want a list of available keyservers, you might want to look there.

Getting Help

gpg --help

is your friend. It will list the most common options to GPG (but not all of them.) Other complete documents are available:

Getting Started

I long resisted the temptation to give an overly-simplified “Getting Started” section here because that may falsely lead you to believe that you’re being secure. As this document has expanded greatly, it’s becoming a better guide. However, the best way to get started with encryption is to go to the home site for GNU Privacy Guard and read the “GNU Privacy Handbook” (available in lots of formats and languages) under the “Guides” section. This will walk you through setting up GPG on your system, including creating your secret keys.

Creating your secret key will start with:

gpg --gen-key

You should probably use the default settings, except it doesn’t hurt to make the key size as large as allowed (4096 bits currently.) The larger the key size, the longer it will take to initially generate your key (and encryption/decryption will be slightly slower. That is a Good Thing, as anyone attempting to break your encryption will also need to spend more time too.)

Generating a Revocation Key

After generating your key, one of the first things you should do is create a revocation certificate:

gpg --gen-revoke --armor --output=RevocationCertificate.asc your@email.address

This certificate can be used to revoke your key if it is ever lost or compromised. Do not neglect this step! Print it out, save it on a disk, and store it safely. It will be short enough that you can type it back in by hand without much effort if you just print it out.

If you lose your secret key or it is compromised, you will want to revoke your key by uploading the revocation certificate to a public keyserver (assuming you uploaded your public key to a public keyserver in the first place. See below.)

If you have multiple unrevoked public keys and you have messages that say something like “I lost that one, this new key supersedes the other ones,” (and I’ve seen this from people who like to claim crypto experience) then I know instantly that I can’t trust you to follow good practice and maintain your secret information, and that I shouldn’t trust you with my secrets. So protect your revocation key like you protect your secret keys. Read on to see why the “this key is my new key, ignore the others” excuse is an immediate “red flag” that should make you suspect either cryptographical incompetence or warn you that the person’s being impersonated.

Using Stronger Algorithms

By default, gpg uses weaker encryption algorithms than it could (especially if you generated your keys using an older version of the software.) This is to ensure compatibility with older versions.

Part of your public key specifies your preferences for the encryption algorithms that you want people to use when communicating with you. These are, by default, somewhat weak. You can view and modify these preferences to make your communications stronger.

To view all of the algorithms supported by your version of gpg, type:

gpg --version

This will give an output that looks something like this:

gpg (GnuPG) 1.4.14
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

You can modify your public key’s cipher preferences by interactively editing your key:

gpg --interactive --edit-key your@email.address

This will display a list of matching public keys. You may need to enter the number of your key in that list so you can edit it.

Hint: You can always type help at the gpg> prompt to see all available commands. There’s lots of fun stuff hidden in here.

Next, show your current algorithm preferences by typing at the gpg> prompt:

showpref

Which produces something like:

Cipher: AES, TWOFISH, CAST5, BLOWFISH, 3DES
Digest: RIPEMD160, SHA1
Compression: ZLIB, ZIP, Uncompressed
Features: Keyserver no-modify

The protocols listed first will be used first. Note that the preferences listed are probably not as strong as your copy of GPG supports, and often the stronger algorithms are not requested at all! You can change these preferences by calling the setpref command. I recommend something like:

setpref AES256 CAMELLIA256 AES192 CAMELLIA192 AES CAMELLIA128 TWOFISH CAST5 3DES SHA512 SHA384 SHA256 SHA224 SHA1 RIPEMD160 ZLIB BZIP2 ZIP Uncompressed

You may want to add other algorithms that your software supports, or you may want to disallow algorithms that you think are too weak.

You can see that it worked by typing:

showpref

Check this very carefully. If everything worked right, you can save, (in some versions there’s just quit) and you will be prompted if you want to save your changes:

save

Note: You should then re-upload your key to a public key server and send it to the people you communicate with. Until people have imported your new key, they will still be using the old algorithms when encrypting to your public key!

Warning: Note that the OpenGPG Key Management document states:

“When setting preferences, you should list the algorithms in the order which you’d like to see them used by someone else when encrypting a message to your key. If you don’t include 3DES, it will be automatically added at the end. Note that there are many factors that go into choosing an algorithm (for example, your key may not be the only recipient), and so the remote OpenPGP application being used to send to you may or may not follow your exact chosen order for a given message. It will, however, only choose an algorithm that is present on the preference list of every recipient key.”

This means that if you’re encrypting to several people at the same time, you can only use the strongest algorithm that the weakest person uses.

Corollary: Don’t be the weakest link in your group! If you are still using weak encryption preferences, you are bringing down the security of the entire group you’re communicating with. You are not weakening the security of your own communications, but those of everyone you communicate with!

Corollary: Inform the weakest links in your group that they could be using stronger ciphers. Point them to this section (Stronger Algorithms) of the documentation and help them fix it. Get their updated public key and help them test their preferences using showpref as described above.

Corollary: Update your keys often, so if someone on your keyring chooses to use stronger algorithms, you respect their preferences.

Technical Note: You may be wondering how these encryption algorithms like AES are even relevant to you if you chose to, say, generate an RSA or DSA public key. RSA and DSA are public-key encryption algorithms, after all, and AES is a symmetric encryption algorithm! I thought we were using public-key encryption here! The answer is that decrypting an encrypted communication in GPG is done in two stages, with both public-key and symmetric algorithms being used:

  1. Public-key decryption: GPG uses your secret encryption key to decrypt a session-only secret key that was encrypted with your public (RSA or DSA) key.
  2. Symmetric decryption: GPG uses this session-only secret key to decrypt the “body” of the message which was encrypted using a symmetric algorithm like AES.

Your public key (RSA or DSA) is only used for the first step. The actual body of the message is encrypted with a (faster) symmetric encryption algorithm, so it’s important to make sure that you’re using strong algorithms for both phases.

Procedure for Verification

Now, since you have my public key, are we secure? Well, no, not at all. Lots of people just getting started with cryptography don’t realize that they have to somehowverify that this key belongs to me. To me, Alan Eliasen. The one who wrote this message. How do you know that the public key posted above is the one I posted? After all, the bad guys could have replaced it somehow.

Listen carefully. This is important. Anyone can generate a public key for any e-mail address. Anyone can post that key to any key server. Only by verifying that the key really belongs to the person you think it does does it give you any security. Without this crucial verification, all that your cryptographic software does is ensures that bits weren’t corrupted during transmission, and prevents casual observers from reading the message. It does not mean that you’re talking to who you think you are. You could be talking to someone else entirely (a bad guy,) or you could be subject to a man-in-the-middle attack.

Update: As proof of the above paragraph, after I posted this document widely, on 2013-07-12, somebody generated a fake public key with my e-mail address and uploaded it to a key server! This is why you need to validate the key directly with the person to make sure you have the right key and the right person! That is, however, an unavoidable problem with public key servers. I thus can’t be mad about it, but I can try to educate people to recognize this possibility and do the right thing by validating my public key with me personally! Note that picking a key from multiple options on a keyserver based on which is newest or largest or by comments about “this is my newest key” is dangerous and wrong.

Still, if you want to send me encrypted e-mail, that may prevent other people from reading it. That’s good, and sometimes that’s all you need. Just understand why I don’t have any reason to trust that you’re who you say you are, and you don’t have any reason to trust that you’re really talking to me unless you’ve verified my key with me. Before I trust you with any secrets, I’ll validate your identity.

Fingerprint

A key could be verified in many ways (such as, I could read you my whole public key, which is really time-consuming and error-prone. It’s also bad because the key you see above can get longer and longer as other people sign it.) The usual alternative is to compare the fingerprint of what you think my public key is with the fingerprint of what I know my public key is.

A fingerprint is a shorter number (usually expressed as a 40-hexadecimal-digit number) that contains a cryptographically strong hash of my public key. It’s shorter than my full key, so it’s not an unfoolable test, but the probability of finding another key with this fingerprint is very small indeed. Infinitesimally small. So small you don’t have to worry about it. If someone else can find a matching fingerprint, they have enough power and money that they could make you vanish from the face of the earth. So, after you’ve imported my key, type:

gpg --fingerprint eliasen@mindspring.com

This will produce output that looks something like below (I have put the fingerprint in bold.)

pub 4096R/ED873D23 2014-07-22
Key fingerprint = EC23 92F2 EDE7 4488 680D A3CF 5F2B 4756 ED87 3D23
uid Alan Eliasen <eliasen@mindspring.com>
sub 4096R/5314E70B 2014-07-22

Then, you need to verify this fingerprint with me. It’s best to do it face-to-face, but if it’s someone you know by voice, you can do it on the phone. If you don’t know the person, check their driver’s license. Ask other people (that you trust) who know them. Even if you don’t know them, at least you’re verifying that the key belongs to the person you’re talking to.

The other person will need to verify that their (unverified) copy of your public key matches what you know your public key to be. So bring a copy of your own fingerprint to the exchange:

gpg --fingerprint your@email.address

Of course, change the e-mail address above to the e-mail address you’re confirming.

Corollary: If someone puts the fingerprint of their key in their e-mail signature, or in a web page, they really aren’t proving their identity. Think about it. If someone’s pretending to be you, and forging your e-mail or your web site, they’d certainly replace the fingerprint too. It’s not enough to rely on. If you see someone with their key fingerprint in their e-mail signature, it’s not a reliable sign that the key with that fingerprint truly belongs to them.

My Key Verification Protocol

If you wish to verify this key, please contact me and I will verify its fingerprint in a public meeting-place. I will be wearing a trenchcoat and a navy blue ascot. You must wear or carry a yellow tulip. Any other flower signifies that contact should be aborted, even if the exchange below is executed correctly. I must not underestimate the necessity of having an adequate stock of proper yellow tulips on hand for this purpose.

I will say “The adobe is filled with an excess of straw this season.”

You must reply “The straw is for the young lambs which roam the heaths near Glasgow in the green, green spring.”

If I am satisfied with your response, I will reply “The greens at Saint Andrew’s are boiled with ham and contain an excess of bitter kale.”

Do not make eye contact or show signs of recognition. If necessary, I will read the hexadecimal digits of the fingerprint while feigning a book order on my cell phone.

Okay, I’m sort of kidding about this section. But you must verify keys with the other person to be truly secure.

If you have verified my key, and trust me (and trust your own verification,) be sure to sign it.

Signing a Key

Now that you’ve verified my identity, and my public key, you need to tell your cryptographical software that you trust my key. Otherwise, your cryptographical software should do the right thing and warn you that you’re communicating with someone that you haven’t verified. It’s telling you that it has no reason to believe that the key you’re using is the one that actually belongs to that person.

Signing keys in GPG

To sign my key from gpg, you’ll do something like:

gpg --sign-key eliasen@mindspring.com

(but see below for a better option.)

This will give you some options for signing the key. Even better would be to edit your signature and trust settings for this user using the interactive menu:

gpg --interactive --edit-key eliasen@mindspring.com

Hint: Type help for the interactive commands. The commands sign and trust are the ones you’re looking for. These allow you to both sign a key and indicate how much you trust me to verify other peoples’ keys. If you think I’m stupid and lax when verifying and signing other peoples’ keys, you’d assign me a low trust rating.

After you’ve signed someone’s key, you should send it back to them so they can show other people that you’ve signed it. You can export their key using:

gpg --export --armor their@email.address

and then sending that output to them. They can then import the changes using

gpg --import

You can also upload that signature to a keyserver, which makes that signature available to the world. See the Publishing your Public Key section below for how to do this.

If you’re really not sure about my identity, and don’t want to vouch for me publicly, you can locally sign my key, which means that you trust it for your own use only:

gpg --lsign-key eliasen@mindspring.com

Hint: If you publicly sign my key without actually verifying it with me, I’m going to assign you a very low trust rating.

Publishing your Public Key

Sure, you can manually send your public key to people you want to communicate with, but what if someone needs to communicate with you securely and you haven’t sent them your public key? The usual way is that you publish your public key to a keyserver so that anyone can import your key. Most of the keyservers in the world mirror each other, so a short time after you have posted your key to one server, it will be propagated to the others. As I have said above, I’ve had good luck for the past decade with pgp.mit.edu.

You have some responsibilities before publishing your public key (or someone else’s) to a keyserver, though. As mentioned above in the Getting Started and Procedure for Verification sections, you better have generated a revocation certificate for your key and put it somewhere very safe. Otherwise, if you lose your secret key, or it becomes compromised, the corresponding public key will sit forever on public keyservers, mocking you and demonstrating that you don’t know how to protect your secrets properly. If you think you can delete a key from a keyserver, rather than revoking it, read the FAQ at MIT’s keyserver. (I think it’s funny and awesome that they have a fake “delete a key” field on their website that just redirects to that FAQ no matter what key you enter.)

If someone has your public key, they can basically do a few things with it:

  1. Encrypt messages that only you can decrypt.
  2. Validate that messages were signed by your secret key with a strong guarantee of certainty, and ensure that those messages were not tampered with or corrupted in transmission.

These are good things. You want people to have your public key. So below are a few methods of publishing your public key to a keyserver. All achieve the same results.

Manual Exporting and Uploading

Now that you have generated a secret key and a public key, how do people find your public key so that can send encrypted mail to you? You can send someone your public key directly by, say, putting it in an email. To generate a copy of your public key that is easily e-mailed, you can do:

gpg --armor --export your@email.address

This will generate a nicely-formatted “ASCII armored” version of your public key which is suitable for e-mailing. “ASCII armor” is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. (Hint: It’ll look something like my public key at the top of the page.)

Note that the lines that begin

-----BEGIN PGP PUBLIC KEY BLOCK----

and end with

-----END PGP PUBLIC KEY BLOCK----

are a necessary part of the message. Don’t forget to include them!

Once you have this ASCII-armored public key, you can manually paste it into a form at a public key server like pgp.mit.edu

Again, just because someone seems to have sent you their public key, there’s no reason to trust that it’s from that person unless you have validated it with them using the instructions in the Procedure for Verification section above. Make sure you verify any keys before trusting them!

Uploading a Public Key via GPG

One way to publish your key to a keyserver is the manual approach from the previous section: export an ASCII-armored key and manually paste it in to a form like the one at pgp.mit.edu.

The other way is to let your gpg program upload the key. You can’t do this by specifying the e-mail address; you need to specify the public key’s hexadecimal ID number. So how do you find this for the key you want to upload?

gpg --list-keys your@email.address

pub 4096R/ED873D23 2014-07-22
uid Alan Eliasen <eliasen@mindspring.com<
sub 4096R/5314E70B 2014-07-22

In the above, my public key id is displayed on a line that says pub and contains an 8-character hexadecimal code (ED873D23 in the sample above.) You will need to know this code to upload to the server.

gpg --send-keys keyID
gpg: sending key ED873D23 to hkp server subkeys.pgp.net

You may want/need to insert --keyserver pgp.mit.edu as options to the above if you want a specific keyserver. (These options have to go before commands like --send-keys. Again, most keyservers mirror each other, but it will take time for keys to propagate across all servers.

Note that after you’ve signed someone else’s public key, indicating that you’ve verified their key and identity and vouch that the key is theirs, you can use this same procedure to upload your signed version of their public key to a keyserver, so people can see you’ve vouched for them. See the Web of Trust section below for more information about this.

Manually Decrypting

So you’ve received a file or message encrypted with GPG, but you don’t have a fancy e-mail plugin to help you decode it. So how do you decode manually? Simple. From the command-line, if you just run gpg it will prompt you for input:

gpg
gpg: Go ahead and type your message ...

From there, you can just cut-and-paste your message directly into gpg, and it will decrypt it, or import keys, or whatever is appropriate to the message. When you’re done pasting, you may need to send your operating system’s “end-of-file” character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems.

If the encrypted data is in a file, you can automatically process it by just passing the filename to gpg on the command-line.

gpg myfilename

The gpg executable will generally just do the right thing with it, prompting you for passwords when necessary, saving output files, etc.

Warning: When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. In Linux, you can use shred -u (shred just overwrites by default; the -u is necessary to delete the file afterward) or wipe commands to delete securely. On Windows, sdelete works well. (Although secure deleting isn’t guaranteed to work on solid state drives or flash drives due to wear-leveling algorithms. If you’re using one of these, and want to securely delete, you have to write over all your free space with a tool like wipe or sdelete) However, don’t believe the hype that you need to do dozens of overwrite steps. This is very likely urban legend, or marketing lies. One overwrite is probably plenty.

Manually Encrypting

Encrypting for E-mail

If you don’t have a fancy e-mail plugin that helps you encrypt your messages, it’s easy enough to do from the command line. You’ll need to save your message to a file.

gpg --encrypt --sign --armor -r recipient@email -r your@email.com filename

There are several important things in this command.

  • --encrypt tells gpg to encrypt the message using public-key encryption.
  • --sign adds a digital signature that lets you guarantee that the message was generated by you and was not corrupted nor modified in transmission. This is theoretically optional, but see the Signing Messages section below for why this is very important.
  • --armor wraps your output in plaintext “ASCII armor”. “ASCII armor” is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. This is necessary if you’re pasting this into the body of an e-mail, or usenet posting, or forum posting, etc.
  • -r recipient Specifies recipients of the message. You must already have imported the public keys of the recipients. You can specify multiple recipients. If you don’t specify recipients on the command-line, gpg will prompt you to enter them interactively. These recipients can also be key IDs.Warning! This is important and interesting! Note that in the example above, your email address is specified as one of the recipients. If you do not explicitly add your own address to the list of recipients, you will not be able to decrypt the message! That is interesting and important and awesome. You may want to write something and send it to someone that you cannot ever possibly be compelled to decrypt! It will be impossible for you to decrypt, even though you wrote it and encrypted it! That is cool. Read the Why Public-Key Encryption is Cool section below for more about why public-key encryption is cool.
  • filename is the filename of the file you’re encrypting. This is not strictly required. If you don’t specify a filename, GPG will listen for input, and you can type a message directly or cut and paste it in. This is awkward, though. When you’re done pasting, you may need to send your operating system’s “end-of-file” character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems.Warning: (I’m repeating this again.) When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. See the warning above for more details on how to do this.

Encrypting Files

GPG is not just for e-mail! You may want to use it to protect your sensitive files also. Encrypting your files is just about like encrypting an e-mail. The simplest command line is:

gpg --encrypt filename

This will prompt you for the recipients (which should include your own e-mail address so you can decrypt it!)

A more complete command-line might look like:

gpg --encrypt --sign -r your@email.com filename

Some interesting things to note and optional arguments:

  • --encrypt tells gpg to encrypt the message using public-key encryption. (See the Symmetric Encryption/Decryption section below for alternate ways to encrypt a file with a simple password and no public keys.)
  • --sign adds a digital signature that lets you guarantee that the message was generated by you and was not corrupted nor modified in transmission. This is theoretically optional, but very important.Think about it: how do you know that someone didn’t replace your encrypted file with a different one? By digitally signing the message, you can get a strong guarantee that you’re the one who encrypted the message and that it hasn’t been tampered with or corrupted. See Signing Messages section below for more on digital signatures.
  • --armor (optional, probably unnecessary) wraps your output in plaintext “ASCII armor”. “ASCII armor” is just a way of turning raw binary data (which will probably get corrupted if you try to send it through most e-mail programs) into a format using only limited ASCII characters, line-wrapped, with appropriate headers, and suitable for e-mailing. This is necessary if you’re pasting this into the body of an e-mail, or usenet posting, or forum posting, etc. Note that this will increase the size of your message on disk.
  • --output filename (optional) specify the output file.
  • -r recipient Specifies recipients of the message. Can also be written --recipient. You must already have imported the public keys of the recipients. You can specify multiple recipients with multiple -r arguments. If you don’t specify recipients on the command-line, gpg will prompt you to enter them interactively. These recipients can also be key IDs.Warning! This is important and interesting! Note that in the example above, your email address is specified as one of the recipients. If you do not explicitly add your own address to the list of recipients, you will not be able to decrypt the file! That is interesting and important and awesome. You may want to create a file for another person that you cannot ever possibly be compelled to decrypt! It will be impossible for you to decrypt, even though you wrote it and encrypted it! That is cool. Read the Why Public-Key Encryption is Cool section below for more about why public-key encryption is cool.
  • filename is the filename of the file you’re encrypting. This is not strictly required. If you don’t specify a filename, GPG will listen for input, and you can type a message directly or cut and paste it in. This is awkward, though. When you’re done pasting, you may need to send your operating system’s “end-of-file” character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems.Warning: (I’m repeating this again.) When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. See the warning above for more details on how to do this.

Attachments and PGP/MIME

What do you do if you want to send an encrypted file attachment in an e-mail?

There is a standard called PGP/MIME that try to standardize the handling of encrypted attchments. You cannot be sure that your recipient’s e-mail client will be able to handle them, so I strongly recommend never using them. Enigmail doesn’t even handle its own attachments that it creates well.

Examples of situations that will cause PGP/MIME or S/MIME attachments to fail or be lost:

  • Most web-based email services.
  • Most phone- and tablet-based email software.
  • List servers or remailers that strip attachments.
  • List servers that just don’t handle all attachments perfectly.
  • Corporate firewalls that remove attachments.
  • Overeager malware scanners.
  • Simple, secure e-mail clients that can only display plaintext.
  • Not-yet-ready-for-attachments e-mail tools like Enigmail itself.

I strongly recommend always sending encrypted messages or encrypted attachments as ASCII-armored OpenPGP blocks directly in the body of an e-mail. This will ensure that any e-mail program will still be able to handle them.

You can hand-encrypt any attachments using:

gpg --armor --encrypt --sign -r your@email.com -r recipient@email.com filename

as outlined in the Encrypting Files section above. Then just paste the results into the body of your e-mail. You can paste in multiple attachments this way, too.

Signing Messages

In addition to encryption, gpg allows you to digitally “sign” messages, which has multiple benefits:

  • It lets you ensure that a message has not been corrupted nor modified in transmission.
  • It allows someone to verify that you signed it. (To be more precise, to verify that the signer of the message used your secret key, given that they’ve verified your public key with you, and that your secret key hasn’t been compromised.)

You should always sign your encrypted messages. Think about it. Everyone potentially has your public key. That’s expected. Anyone can encrypt a message to you using your public key, and pretend that it’s from someone you know. (It’s easy to spoof e-mails, but that’s another discussion.) Only if you verify (via the digital signature) that the message was signed by someone whose key you have verified, can you trust the communication.

Corollary: You should actively distrust unsigned encrypted communications. If someone’s trying to impersonate your friends, they’ll just conveniently “forget” to sign their messages.

A signed message gives a mathematically very strong certainty that the message was signed by you.

In your e-mail client, always choose to sign and encrypt a message. Below are some ways to sign messages manually.

Signing a Plaintext Message

Sometimes you just want to sign an unencrypted message to make it clear that you produced it and that it hasn’t been tampered with nor corrupted in transmission. For example:

  • Sending an important vote.
  • Important business communications.
  • Maybe you’re mailing a URL that looks suspicious and spammy, and your recipient wants to validate that it’s actually from you and not from a spammer or a virus. (Saying “this is really from me” in the e-mail is not good enough!)
  • Being very certain that the message is not corrupted in transmission.
  • Allowing recipients to verify that data comes from you and is valid. For example, a school could prove that test scores came from them and were not tampered with. (Institutions should use this more!)

The --clearsign option will wrap the message in an ASCII-armored signature but will not otherwise modify its contents. This allows even the losers who don’t use gpg to read the body of the message, but allows gpg users to verify that you wrote it and that the message wasn’t changed.

gpg --clearsign filename

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I vote YES on this important measure.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: See Alan's GPG guide at https://futureboy.us/pgp.html

iQIcBAEBCAAGBQJT3MFeAAoJEF8rR1bthz0jslMP/RMRODVKLmLwZ3sMR62COGc/
0yQSh3c37qkkVjD0RvgdziHuCSSYelhNl7UMQofpdLonnJgPW3svlftE3Gn11JLp
ZYv2iMwCzwyM2eLYpSQoJBNnGZzQDGnZRBkFOwdkkohUSBjhPjiszYw3KwnpsuxG
I+m81IMJATR0wOylLumVdjbvS1/f9bOzBRvhgu2HS54lfPnl162RRZpycrrb5IOi
07QWIlUGVUdAxFUq4Jlm99KB17lQhri3zm6m7O5k0faD3IKFRTQGKseq7j88pRs6
j85v/cc35CHW9+66jcz7Y3UtOIj3gqDQd/Wj05YP01QSwSCuuVAezvXngljF8fLP
OKQhFpLoLnWvDPgX3nKwGbX52qZwLGN0bZduhOmMPYwKAEFAYDOOW7q+i/dyz5xT
od54j32QiNkSqDCVkvOT6dKiCdCa8GvtwwXPKa9X7+VZB2xYeJorJiaIesD7wyVN
CQDx11uMGMkpZ/BmCIA5mDIkDnUTIxHxNFpn2kS6nHJqmJ/LleTpAKLhPWuY1U28
YVraBzmAZ/Wj2Frq0utPi4cFf5r3x9jXIzie4fYrUjMKCN+CNfLL15Py/z9OY1ux
vvYdMiLAzL1Ujvjpyw7sCdc2KnbXaM9jmbBGjmVCMX/wGcGKT6cIxYnkR4NOW62L
jaBgelaHIL5kZ+E/kpS6
=wh+e
-----END PGP SIGNATURE-----

Verifying Signatures

People who have verified your public key can verify messages that you’ve signed by passing the output back into gpg:

gpg --verify vote.txt.asc

gpg: Signature made Sat 02 Aug 2014 04:45:50 AM MDT using RSA key ID ED873D23
gpg: Good signature from "Alan Eliasen <eliasen@mindspring.com>"

If they haven’t verified and signed your public key, then they will be warned that the key is untrusted. This means that all that they can tell for certain is that the message wasn’t corrupted in transmission, but it really could have been written by anyone! Beware “Untrusted good signature!” It means that the signature is by someone whose fingerprint you haven’t verified.

Detached Signature

Sometimes you want to sign a file, but without modifying it like the --clearsign option above does, because people would need to edit the file or use gpg to get at the contents.

Say, you’re sending an executable file to someone. You don’t want to tamper with the executable file, but executable files are scary and potentially very dangerous. So how can you guarantee to the recipient that nobody has tampered with the file and that it actually came from you? By creating a “detached signature” which is a separate file that contains a signature for the specified file. This is achieved through the --detach-sign command:

gpg --detach-sign filename

Then you ship the signature file along with the original file. The recipient can verify that you signed the file and that it has not been modified with the --verifycommand:

gpg --verify filename.sig

gpg: Signature made Sat 02 Aug 2014 04:45:50 AM MDT using RSA key ID ED873D23
gpg: Good signature from "Alan Eliasen <eliasen@mindspring.com>"

Proving You Wrote Something but Remaining Temporarily Anonymous

Let’s say you found out that a huge company (we’ll call them Mapple) wrote a really crappy incompetent insecure website that leaked a lot of their customers’ information that anyone could access trivially by adding 1 to a number.

Now, you’re not sure if the company is awesome and honest and will pay you a handsome bug bounty for pointing out their incompetent security hole and helping them protect their customers’ information, or if they are psychotic morons who will claim post-facto that your access of information they intentionally published on a public webserver without any access control was “unauthorized” and have you charged under the insanely incompetently-written and outdated Computer Fraud and Abuse Act (CFAA).

So, how do you report this anonymously? Well, one very strong way would be to generate a new keypair without your name on it, publish that public key, and sign all your messages with the corresponding secret key. This lets you do a few things:

  • You can prove that all subsequent messages signed with the same key are from the same person, even if you jump to different e-mail addresses or communication channels.
  • If they decide to be honest and offer you a bounty for your services to them and their customers, you can prove in the future that you’re the person in possession of the corresponding secret key that signed the messages, for example, by decrypting something sent to you encrypted with your public key. Nobody else would be able to falsely claim that they’re the submitter without verifying that they have the corresponding secret key.
  • If they are evil about it, you can remain anonymous to them. If you want to prove to others that you made the disclosure, you can, by signing a message with the same secret key or decrypting information sent to you that was encrypted with your public key (by using your secret key.)

(This is a mathematically super-strong version of the old trick of ripping a dollar bill in half, and sending half of it to someone. If they want to verify your identity, only you will have the other half of the bill. A dollar bill, with distinctive tearing pattern and matching serial numbers, is hard to forge.)

Updating Keys

People are constantly updating their keys for various reasons:

  • Keys get compromised or lost and they are revoked.
  • Keys are signed by more people, building a Web of Trust.
  • Users change the encryption algorithms they prefer. (See the Using Stronger Algorithms section for more about this.)

Updates to keys can be published to public key servers, including new signatures. You can periodically update your keys by using

gpg --refresh-keys

This lets you ensure that the keys you’re using haven’t been revoked. You might even find that more people have signed your public key. (And they better have validated your key fingerprint and your identity using the verification procedure outlined above, or they can’t be trusted to sign keys properly and you should assign them a low trust rating!)

Note that other people can sign your public key and upload the signed key to a public webserver! So you might even find that your own key has been updated!

Listing Your Keys

You can get a list of the keys on your keyring and their corresponding key IDs with:

gpg --list-keys

If you enter part of the name or e-mail address or key ID as the last argument on the command-line, then only keys that match that pattern will be listed.

gpg --list-keys Alan

Who Signed My Key?

Now that you’ve updated keys from a keyserver, you might want to see who has signed your key. After all, anyone can sign any key and re-upload that key to a key server. You can see the signatures with the --list-sigs command to gpg:

gpg --list-sigs your@email.address

Or you can browse your key on a public keyserver, like pgp.mit.edu. This is advantageous because if you haven’t imported someone’s key yet, they will just show up as a key ID number.

Again, if someone signed your key without validating the fingerprint with you, they are actively damaging the web of trust. You should import their public key just so you can tell your software to actively distrust it as outlined in the Signing a Key section.

(After I published this document, an out-of-control signer whom I’ve never met signed my key and published the changes to a public website. I had to download his public key so I could tell gpg to actively distrust his signatures!)

Building a Web of Trust

In the examples above, I stress the importance of verifying people’s public keys with them. But sometimes you can’t do that directly. So how can you verify someone else’s public key?

Let’s say I want to talk to Bob. I’ve downloaded a public key with his name from a keyserver, but I can’t be sure that key belongs to him. I could maybe call him on the phone and verify his key that way, but I don’t know his voice, and I don’t have his phone number. Or maybe he’s even under duress.

Luckily, my friend Alice has signed his public key. I trust Alice to have verified his key properly. I have validated and trusted Alice’s public key personally. Thus I have a good reason to believe that Bob’s key really belongs to him.

This is why it’s important to validate other people’s keys very carefully and to build a web of trust–so you can communicate with people whose keys you can’t personally verify.

See the Signing a Key section above to see how to sign someone else’s key and upload it to a keyserver.

Conversely, you may not want to publicly sign the keys of people you communicate with. You may not want others to know who you communicate with. You may have more than one keypair, and use them selectively for communications with a single person once they’ve demonstrated strong cryptographic practices.

This is serious business. An example from Syria shows how people die when others don’t protect their communications.

If you don’t want anyone to be able to analyze who you’re talking to, even by traffic analysis of key IDs, you can specify hidden recipients in your messages.

Good Encryption Practices

By using encryption improperly, you can make your encrypted communications easier to break. Some of the tips here are speculative and may not apply to all cryptographic algorithms, but many cryptographic algorithms are subject to common types of attacks. These tips will help mitigate those potential weaknesses if algorithms are found to be vulnerable to these types of attacks.

TODO: Improve ALL THE THINGS. Send me more examples of good and bad cryptographic practice, and ciphers that have been broken by poor cryptographic practice.

  • Don’t be predictable. This is the way that much crypto has historically been broken–by knowing words or phrases that are likely to occur in the message. This is known as a “known-plaintext” attack. For example, the WWII German Enigma machine codes were partially broken because people would end with expected phrases like “Heil Hitler!” or from spelling out numbers. (Looking for the number “eins”, (1), the most common number, was a useful tactic in breaking Enigma.)You think this is academic and known-plaintext attacks can’t happen? Well, take a look at this recent break on the widely-used RC4 cipher. (It’s used in SSL/TLS and in WEP/WPA in wi-fi.) It was found that if you knew a small amount of plaintext, you could recover the rest of the message (given a fairly large amount of encrypted communications, to be sure.) With as little as 6 bytes of plaintext, and a large number of communications, the rest of the message could be decrypted with high probability. (The more bytes are known, the easier it is to break.) Also, keep in mind that breaks in cryptographic algorithms only get worse.
  • Don’t be polite. As a corollary of the above, don’t start and end your message with predictable phrases or pleasantries.
  • Don’t send HTML-formatted encrypted emails. There’s a large amount of predictable boilerplate in HTML.
  • No signatures! As a corollary of the above, when sending encrypted messages, don’t include your usual .sig file with your name, e-mail address, phone number, password, website, company policy, etc.This doesn’t mean “no cryptographic signatures!” You still want cryptographically strong signatures like the kind you get with --sign. Smart e-mail add-ons like Thunderbird with Enigmail can suppress your signature when using encryption. Or you should encrypt just the meat of your email (and not the signature) if you need that silly signature.
  • Don’t quote previously-encrypted text. When replying to an encrypted message, don’t quote the original text. Again, having large stretches of expected text has been the downfall of many cryptographic algorithms.
  • Don’t encrypt the same message multiple times. Some codes have weaknesses that if the same plaintext message is encoded several times (say, to several different people, or to the same person multiple times,) then more information can be derived about the contents or the key. If someone isn’t able to read your encrypted message, don’t send it again. After all, they’re not following good cryptographic practice if they can’t read it, and you should limit encrypted communications with them. Or, if you must send it again, alter it as much as possible before encrypting and sending it again. If encrypting the same message to multiple people, encrypt to all of them at once (assuming you want them to know who you’re communicating with. They will at least see the key ID numbers.)
  • Don’t have encrypted and unencrypted versions of the same information. As noted above, gpg does not automatically delete the plaintext version of a file when you encrypt it! Read that section on securely deleting files if possible.
  • Garbage is good. One of the hard problems in cryptography is identifying when a message has been successfully decrypted. How do you know? When it all comes out as mostly alphanumeric characters? When its word frequency looks like English? Make it hard for the bad guys. Jam in a bunch of random bytes into your message if you can. It’ll make it harder to even detect the fact that the message was decrypted properly. Send your friends encrypted random bytes every day just for fun because screw the surveillance state we live in! If everyone did this, it would be utterly prohibitive to try and decrypt all of the random data flying around.
  • If it’s received encrypted, store it encrypted. Some e-mailer plugins will offer to decrypt messages and store the decrypted versions in your mail folder. Don’t do this. It allows someone to mount a chosen-plaintext attack on you just by sending you an encrypted message. Yes, it will make your messages impossible to search for content. But that’s good.
  • Don’t encrypt stuff from untrusted sources. There is a class of attacks called a “chosen-plaintext” attack. Some encryption algorithms can be weakened or completely defeated if the attacker is allowed to choose the text that you are going to encrypt with your key. Always refuse to encrypt something specific that a third party asks you to encrypt, especially if it’s lengthy.
  • Hide your encryption entirely! There’s a branch of cryptography called “steganography” which hides secret communications in innocuous places that are very hard to detect. For example, by slightly modifying the least-significant-bits in the pixels of a JPEG image, you can hide encrypted messages in pictures of kittens! Or, you can hide them by adding slight, undetectable noise to audio files.It becomes very difficult and expensive to determine that a particular image even contains steganographic content. That’s the best way to hide your information, especially as the NSA has decided that using cryptography to protect your privacy is probable cause that you’re a terrorist, and they allow themselves to keep encrypted content “for as long as necessary” to break it.

    I have built some web-based Steganographic Tools that let you experiment with steganography from your browser! If you want to be more secure, of course, you’ll run the steganography tools on your own machine. That page tells you more about the steghide program. (Hint: in Fedora it’s yum install steghide )

Symmetric Encryption/Decryption

Sometimes you don’t want to use public key encryption. You can use old-fashioned “symmetrical” encryption where everyone shares a common password. In gpg, you do this by using --symmetric instead of --encrypt:

gpg --symmetric filename

gpg will then prompt you for a password.

Warning: (I’m repeating this again.) When gpg encrypts or decrypts a file, it usually leaves the original file intact!. You must remember to delete the original file yourself, securely if possible. See the warning above for more details on how to do this.

If you want to paste the encrypted file into an e-mail or something, you can use the --armor option.

The encrypted file can be decrypted by passing it back into gpg:

gpg filename.gpg

If you want to force the encryption algorithm used (the default is maybe CAST5), you can add the --cipher-algo name command-line option, for example --cipher-algo AES256 . The list of available encryption algorithms in your version of gpg can be found by running the gpg --version command.

Symmetric encryption has its problems. It doesn’t let you simultaneously sign the message to indicate that it hasn’t been tampered with or replaced with another file that someone else generated! (You can, however, sign it manually later using the techniques in the Signing Messages section, but it’s theoretically possible that an attacker can replace that file in the brief time between when you encrypted it and when you signed it.)

If you use symmetric encryption, you also need to solve the age-old problem “how do I communicate the password securely?”

Why Public-Key Encryption is Cool

  • In short, public-key encryption solves the age-old problem “how do I communicate a password securely?” You no longer have to. You just need the other person’s public key, which can be published to the world.
  • You can also encrypt a message that you can not decrypt! This may sound silly, but you may want to write something to someone that you cannot ever possibly be compelled to decrypt! It will be impossible for you to decrypt, even though you wrote it and encrypted it and even if you have the file in your possession and even if you have all your secret keys and you know all of your own passwords and have them written down! That is cool. (You can smile serenely while they’re beating you with a rubber hose, knowing that you can’t endanger the lives of your sources, nor give up your rights, even if you felt like that might be entertaining for a change.) You can see how to do this physically in the Encrypting Messages You Can’t Decrypt section.This actually has many important and practical uses:
    • If you’re a reporter (or other human) traveling abroad, you can encrypt materials using public-key encryption, to someone else’s key, butwithout encrypting to your own public key. (Warning: some tools will encrypt to yourself by default. Read on.) It’s easy to create a message that you can never possibly decrypt yourself, and cannot possibly be compelled to do so! Ever! You could encrypt them, say, using only the public key belonging to your newspaper’s editor or lawyer. (And if your newspaper’s editor and lawyer don’t have public keys, have them contact me and I will help them. They need to do this. Now. Before they kill people.) You can be detained and couldn’t ever be compelled to give up the password, as you never had it!You don’t have to be in Syria (although journalists who don’t use encryption kill people; read the link) or North Korea for this type of Orwellian police state coercion to happen. Even the otherwise-civilized United Kingdom has vile horrendous laws that can jail you without trial if you don’t give up passwords.

      Edward Snowden has also stated that he has in his possession encrypted documents that he cannot possibly be compelled to decrypt, even under torture. (But maybe other trusted people potentially can decrypt them.) Public-key encryption is probably what he was hinting at. Nice work.

      Also see the Hidden Recipients section of this document to see how to hide the people to whom you’ve encrypted. That may be veryimportant for journalists or dissidents or ordinary people who want to assert their rights to free association. It also allows you to post encrypted messages to public forums without anyone knowing who you’re talking to.

      Also see my Steganography tools which let you hide the fact that any hidden communications are happening at all! You can hide secret communications in pictures of kitties.

    • Let’s say you have a web server that collects very sensitive user information. You don’t trust the security of the web server, but you have to keep the information on that web server for a while before you move it elsewhere. Say, to a computer completely disconnected from the outside world. With public key encryption, you can encrypt information with a public key stored on the web server. However, the secret key would not ever be kept on that server! Even if someone breaks your web server wide open and has total access to every single file, andevery single algorithm, and the public key, they will still never, ever be able to decrypt the private information on the server because the secret key needed to decrypt it is not on the server at all! Miracles!
    • If you rent space in a server farm, this can prevent malicious administrators at the hosting company (who probably hold superuser access on your machine, and can read all your files) from being able to do anything with your data. And it keeps your web server administrator or database administrator from seeing that sensitive data, even if they have complete access to every file on the computer.
    • A real-world example of storing sensitive communications: The Federal Communication Commission’s (FCC’s) Lifeline subsidized cell-phone program for low-income people leaked highly sensitive customer information for over 170,000 people, including Social Security numbers, birth dates, home addresses, and sensitive details about family finances from a public web server. Think about how you could use public-key encryption to collect and encrypt this data securely on the webserver, and only be able to decrypt it somewhere else much safer.

    Again, see how to do this in the Encrypting Messages You Can’t Decrypt section.

  • It’s easy to revoke access to one member of a group. If everyone in a group shared a password, it would be very difficult to remove one person’s access. A different password might have to be created, and that password would have to be communicated securely to all other members of a group. Public-key encryption means that you can control exactly who is allowed to read future communications. If you don’t want someone to read it, just stop encrypting to that person’s public key. Even if they can still see your encrypted communications (like on a public mailing list,) they will no longer be able to decrypt it.

Fun Tips and Tricks

Here are a collection of fun tips and tricks and puzzles for using GPG. Please send me more.

Verbose Information

You can use the -vv command-line option to gpg to give verbose output about what algorithms are actually being used. (Note that if you’re pasting in decrypted text, after you’re done pasting, you may need to send your operating system’s “end-of-file” character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems.)

gpg --list-packets can list the packets of any GPG file and give details on what’s contained therein. This tends to output not-very-meaningful numeric data about which encryption algorithms were used, but you can decode these by looking at the specification for the Open PGP standard, RFC 4880, specifically Section 9.

You can also use programs like pgpdump to see what’s included in a PGP message.

Also see the Automating GPG section below to see more options for dumping detailed information about what GPG is doing.

Requiring Multiple Decrypts

You can encrypt documents that require several people must cooperate to decrypt, by encrypting with multiple passes, specifying a different recipient each time. They will need to decrypt in the reverse order that you encrypted.

TODO: Make an example, preferably one that writes no intermediate files (e.g. output to stdout using --output -) and doesn’t make you enter passwords multiple times. Naïve versions make gpg complain with weird “broken pipe” errors and races in password entry.

Hidden Recipients

Sometimes you want to hide the recipients of your message from any snoopers. Normally, the key IDs of the recipients are part of the message. However, you can hide these by specifying --hidden-recipient recipient for each recipient you wish to remain hidden (instead of using the -r or --recipient flag to specify recipients.) The decrypting program will have to try all available secret keys to try and decrypt the message. (Hidden recipients’ key IDs show up as all zeroes in the encrypted message.)

The --throw-keyids command-line option is essentially the same as using --hidden-recipient for all recipients.

There are other interesting options for hiding recipients in the GPG key-related options documentation.

Encrypting Messages You Can’t Decrypt

The section Why Public-Key Encryption is Cool explains reasons that you might want to create an encrypted message that you can never be compelled to decrypt. This section discusses how that is performed.

In GPG

When you encrypt a message in GPG from the command-line, it does not encrypt to you by default! You would need to specify your own e-mail address as a recipient with the -r recipient@email.com option for you to be able to decrypt it.

(See the Manually Encrypting for E-mail section, including the warning, or the Encrypting Files section, including the warning.)

Thus, there’s nothing to do when using gpg on the command-line other than remembering not to specify your own e-mail address as a recipient. (Note: You can change the “encrypt to self” behavior in your gnupg.conf file, so be careful if you’ve modified that.)

This is why I encourage people to learn and use the GPG command-line for sensitive communications. Its defaults are usually safer than what your e-mail program exposes to you.

Migrating to a New Key

This section of the document describes the process for migrating to a new GPG key, which is two different but related problems:

  • Creating a new public/secret keypair key for yourself which you will then communicate to others.
  • Updating when someone else generates a new public key.

These are addressed in the sections below.

Creating Your Own New Key

Sometimes you want to generate a new public key for yourself, and migrate away from the old one. There are a few steps to this process:

  • Generate the new key. For this step, you will probably want the old and new keys to co-exist on your keyring at the same time. As noted in the Getting Started section, you will begin the process of creating a new key with:

    gpg --gen-key

  • Know your old and new key IDs. Throughout most of this document, you use e-mail addresses to identify keys. However, once you have more than one key for a given e-mail address, things get a bit trickier. GPG behaves somewhat dangerously and uses the first secret key in your keyring, unless you explicitly tell it otherwise. Thus, you will need to know the key IDs of your old and new keys, and use them in the right places below.You can list your secret keys with:

    gpg --list-secret-keys

    or the equivalent:

    gpg -K

    (note that that’s a capital K. A lowercase k lists all keys.)

    This produces output something like:

    sec 1024D/B05676B1 2002-06-26
    uid Alan Eliasen (http://futureboy.homeip.net/) <eliasen@mindspring.com>
    ssb 1024g/70AC29FB 2002-06-26

    sec 4096R/ED873D23 2014-07-22
    uid Alan Eliasen <eliasen@mindspring.com>
    ssb 4096R/5314E70B 2014-07-22

    I have highlighted the key IDs in bold. They appear on a line beginning with sec. As you can see by the creation dates, the old key ID is B05676B1 and the new key ID is ED873D23. Yours will be different, of course. Make a note of them.

  • Create a revocation certificate for the new key. This will let you revoke the key if you lose it. See the directions in the Generating a Revocation Key section of the documentation, but substitute your new key ID for the e-mail address. You may also want to change the filename if you already have a revocation key for your old key.
  • Ensure that the new key uses strong cryptography preferences. By default, the encryption preferences specified in your public key are probably not as strong as they should be. Follow the procedure in the Using Stronger Algorithms section of the documentation, but substitute your new key ID for your e-mail address. That is, the command-line will be:

    gpg --interactive --edit-key newKeyID

  • Sign the new key with your old key. If people have your old key, this helps them trust that the new key was generated by you.When signing a message, the gpg options --local-user keyID or the equivalent -u keyID lets you specify which key is doing the signing. Thus, to sign the new key with your old key, you would use the command:

    gpg -u oldKeyID --sign-key newKeyID

  • (Optional) Trust the old key’s signatures. You may have signed other peoples’ keys with your old key. You can tell the new key to trust signatures made by the old key using the procedures in the Signing a Key section, specifically the trust command. The command-line may look like:

    gpg -u newKeyID --interactive --edit-key oldKeyID

    And then using the command trust followed by save. (Which in some versions is just quit.)

  • Set the new key as your default key. As noted before, GPG uses the first secret key in your keyring to sign messages. You thus have a few options to make gpg use your new key by default. Choose one of the options below:
    1. (Recommended) Set the default-key option in your gpg.conf file to your new key ID. (See the Sandbox section to see where yourgpg.conf file may reside.) The line in the file will look something like:

      default-key newKeyID

    2. (Not recommended) This is ponderous and easy to forget, but you can specify the new key ID on the command-line with each signing command: -u newKeyID
    3. (Optional) Disable the old key in your keyring. You’d think that this should not be necessary if you followed step 1, but be warned that GPG and Enigmail will encrypt to the old key ID and sign with the old key ID if you specify your e-mail address as one of the recipients, as it uses the first key that matches the e-mail address. Ugh. The command would be:

      gpg --interactive --edit-key oldKeyID

      And then using the command disable followed by save. (Which in some versions is apparently just quit). You can theoretically re-enable it in the future using enable.

    4. (Optional, possibly dangerous) If you’re absolutely sure that you’ll never need the old secret key, you can delete it. Keep in mind that this will make it impossible for you to decrypt any old communications that were encrypted to the old key! You probably don’t want to do this, so I’m not going to tell you how, (but I’ll say that the help command from the --edit-key mode is your friend, and contains lots of interesting tricks. Take a look!)Because of the glaring problems and outright bugs in Enigmail and GPG’s handling of multiple keys for the same e-mail address, it’s not a bad idea to delete the old key when you can finally be free of it.
  • Communicate the new key to people who have your old key. One of the best ways to do so is to create a migration document that explains your reasons, your old and new key information, and sign that message with your old key using:

    gpg -u oldKeyID --clearsign [filename]

    I have a sample migration document that you are free to use and modify.

  • Import the new signatures from your friends. People may publicly sign your key and return it to you, or upload the signed key to a keyserver. See the Signing a Key section of the documentation for more information. Also, be sure to periodically refresh your keys from a public keyserver using:

    gpg --refresh-keys

  • (Optional) Upload the new key to a keyserver. See the Publishing your Public Key section for how to do this. This step is important if people have signed your key and sent it back directly to you, as their signatures will not appear on public keyservers until someone uploads to a keyserver.
  • (Optional, Potentially Dangerous) Revoke the old key. If you know what you’re doing, you can (and eventually should) revoke the old key. Since this is somewhat dangerous, I’m not going to give you explicit steps, but this section of the GPG guide will get you started. (Link opens in new window.)Revoking a public key is not the end of the world, though. That guide notes that:

    “A revoked public key can still be used to verify signatures made by you in the past, but it cannot be used to encrypt future messages to you. It also does not affect your ability to decrypt messages sent to you in the past if you still do have access to the private key.”

    However, this paragraph is deceptive if not outright wrong! People can and will continue to encrypt future messages to you using the revoked key if they don’t know about the revocation, and haven’t updated your key! They will only know about the revocation if they periodically refresh your key from a keyserver using something like:

    gpg --refresh-keys

    Since you have no guarantee that people do that (and few people do it regularly, in my experience,) then you need to make sure that you communicate the revocation to people you have communicated with in the past. Again, see the “Communicate the new key…” section above for a sample document explaining how to do this.

Using Someone Else’s New Public Key

People that you communicate with may generate new public keys, and you need to ensure that the new key is valid, and that you are using the new key instead of the old key. There are a few steps to this process:

  • Import the new key. If the person emails you the new key directly, it should be trivial to import. Otherwise, you can import it with

    gpg --import

    either specifying a filename to read from or pasting the new key in directly. (When you’re done pasting, you may need to send your operating system’s “end-of-file” character. This is Ctrl-D in most Unixlike systems and Ctrl-Z in Windows-like systems.)

    You may also fetch the new key from a keyserver. Be sure to read on and validate that the person actually uploaded it!

  • Know their old and new key IDs. Once you have multiple keys for a person, GPG behaves very badly. It uses the key for the first e-mail address that matches, and ignores the others!For the next few steps, you will need to know the key IDs for the old and the new keys. You can list all keys associated with their e-mail address by doing:

    gpg --list-keys their@email.address

    or the equivalent:

    gpg -k their@email.address

    This produces output something like:

    pub 1024D/B05676B1 2002-06-26
    uid Alan Eliasen (http://futureboy.homeip.net/) <eliasen@mindspring.com>
    sub 1024g/70AC29FB 2002-06-26

    pub 4096R/ED873D23 2014-07-22
    uid Alan Eliasen <eliasen@mindspring.com>
    sub 4096R/5314E70B 2014-07-22

    I have highlighted the key IDs in bold. They appear on a line beginning with pub. As you can see by the creation dates, the old key ID is B05676B1 and the new key ID is ED873D23. Yours will be different, of course. Make a note of them. You will need them in the following steps.

  • Validate the new key with the person. You should always be warned that anyone can generate a public key for any e-mail address. Anyone can post that key to any key server, so you need to follow the instructions in the Procedure or Verification section of the document to validate that key with the person!If the person has signed the new key with the old key, (and they should have!) then you can perform another procedure to have a strong certainty that whoever is in control of the old key created the new key. (But if the old key was stolen/compromised, you need to be extra careful!) You can check signatures on the new key by running:

    gpg --check-sigs newKeyID

    This will produce output that looks something like:

    pub 4096R/ED873D23 2014-07-22
    uid Alan Eliasen <eliasen@mindspring.com>
    sig!3 ED873D23 2014-07-22 Alan Eliasen <eliasen@mindspring.com>
    sig! B05676B1 2014-07-22 Alan Eliasen (http://futureboy.homeip.net/) <eliasen@mindspring.com>
    sub 4096R/5314E70B 2014-07-22
    sig! ED873D23 2014-07-22 Alan Eliasen <eliasen@mindspring.com>

    The exclamation points following sig are the important things here. The line in bold, with the old key ID, indicates that the old key (which you can identify by the key id you found in an earlier step) signed the new key and the exclamation point after sig indicates that the signature check passed.

  • Sign the new key. Once you have validated the new key with the person, you can sign the key. See the Signing a Key section above to see how to sign someone else’s key, but note that you’ll have to substitute the new key ID instead of the e-mail address, or GPG will likely just give you the first matching e-mail address (which is the old key):

    gpg --interactive --edit-key newKeyID

  • (Optional) Send the signed key to its owner. Again, see the Signing a Key section above to see how to sign someone else’s key and export it for e-mailing, or to send it to a keyserver.
  • Delete or disable the old key. Since you now have both keys on your keyring and you no longer want to accidentally use the old key, you should delete or disable the old key.With all the problems with GPG and Enigmail’s handling of multiple keys for the same e-mail address, deleting it is by far the safest option, but simply disabling it means that it should no longer be used for encryption (although the bugs listed above for Enigmail leave me with little confidence in its ability to choose the right key.) However, GPG may still trust signatures made by a disabled key, so if the other person’s old key was stolen (and not revoked) then you might be at risk of accidentally trusting it!

    To disable or delete the old key, do:

    gpg --interactive --edit-key oldKeyID

    Check that you have the correct key, and then type either disable or delete. After that, type save and save your changes.

    Note that some versions of GPG appear not to have a delete command from the interactive menu, so you may have to do something like:

    gpg --delete-keys oldKeyID

    Keysigning Party

    A keysigning party is just a bunch of repetitions of the Procedure for Verification described above. You meet other people, validate their identities, and exchange fingerprints of your public keys. Later, usually after the party, you can download their public keys from a keyserver, verify that the fingerprint you got from the person matches the one you downloaded from the keyserver, and then sign the key and send the signed key to its owner. You don’t need to (and are often warned not to) bring a computer to the keysigning party, as long as you are prepared using the guidelines below:

    • Before the keysigning party:
      1. Print out a bunch of copies of your public key’s fingerprint on strips of paper. Keep them safely in your possession until the keysigning party:

        gpg --fingerprint your@email.address

        It may look something like this (I’ve put the fingerprint, name, and e-mail address in bold.)

        pub 4096R/ED873D23 2014-07-22
        Key fingerprint = EC23 92F2 EDE7 4488 680D  A3CF 5F2B 4756 ED87 3D23
        uid Alan Eliasen <eliasen@mindspring.com>
        sub 4096R/5314E70B 2014-07-22

        Here’s a fancier one I printed out 4 to a page for a keysigning party at DEFCON: DEFCON fingerprint document.

      2. Bring a pen, some paper, and a photo ID. You may wish to obscure sensitive details on your photo ID (e.g. license number, address, birthdate) if you’re not meeting with people you know and trust. Blue painter’s tape works well for this.
      3. If your key is on a public keyserver, then there is no step 3! You’re ready! If your public key isn’t listed on a keyserver, then either publish it to one or, (less friendly,) provide a way for others to download it. (Say, by publishing a URL on the paper that contains your fingerprint.) I definitely don’t recommend exchanging flash drives at a keysigning party!
    • During the keysigning party:For each person you meet at the keysigning party:
      • Exchange paper copies of your fingerprints. You should both give and receive one, but it does not necessarily have to be symmetrical. (If you run out of pieces of paper, you can always copy fingerprints by hand, or take a picture of one, etc.)
      • Attempt to validate the other person’s identity, usually by asking to see their photo id if you don’t know them otherwise. Be courteous. You don’t have to share your ID with anyone you don’t want to, and they don’t have to share with you. Again, it’s good to mask out sensitive details on your ID, (like with blue painter’s tape.)
      • Once the identity is validated, sign or initial the fingerprint you received from them, and keep it in a secure place. You will need it later.
      • (Optional) Go around the room in a group with people you know. If you personally know someone that you’re exchanging keys with, let your friends know that, and ask them to do the same. Introduce each other. It enhances the trust level.
      • (Optional) Ask the person if they have a photo of themself in their public key. (You can attach a small photo to your public key, which makes it harder to impersonate you in person.) If they do, you might ask to take a picture of them to compare with the picture in the public key later.
    • After the keysigning party:After the keysigning party is when you usually do the actual signing of keys. For each person that you met:
      1. Import their public key from a keyserver. Again, note that the last 8 or 16 hexadecimal digits of the fingerprint are their short or long public key ID, respectively. For example, if all you have is the fingerprint:

        EC23 92F2 EDE7 4488 680D  A3CF 5F2B 4756 ED87 3D23

        Then you can instantly determine the short key ID, which is the last 8 hexadecimal digits of that fingerprint (removing spaces), which givesED873D23. (The long key ID is the last 16 digits.)

        With just that number, you can request their public key from a keyserver:

        gpg --recv-keys keyID

        You will see something like:

        gpg: requesting key ED873D23 from hkp server keys.gnupg.net
        gpg: key ED873D23: public key "Alan Eliasen <eliasen@mindspring.com>" imported
        gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
        gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
        gpg: Total number processed: 1
        gpg: imported: 1 (RSA: 1)

        (You can even fetch public keys from keyservers using all 40 digits of the full fingerprint (with spaces removed) but people usually use the short key ID because it’s easier to type from a piece of paper. You will still verify the full fingerprint in the next steps.)

        You can also search for keys by e-mail address instead of key ID, using gpg --search-keys their@email.address but if you don’t even have the e-mail address, the fingerprint alone is sufficient.

        (Note that with just an 8-hex-digit short key ID, it’s possible that there may be key collisions when downloading from a keyserver. You can reduce this possibility by using the 16- or 40-bit fingerprint. See the Short key IDs are Bad News section of this document if you want to know more about key collisions.)

      2. Generate the local fingerprint of the key you imported. This verifies that the public key you received has the proper fingerprint:

        gpg --fingerprint keyID

        Again, you could also search by e-mail address instead of key ID. See the Fingerprint section of this document to see how to verify fingerprints in Enigmail.

      3. Verify that this fingerprint matches the one you have on paper. You just do this with your eyes, comparing the 40-hexadecimal-digit numbers.
      4. Sign the key if everything matches. See the Signing a Key section for detailed information on how to do this. You may sign the key publicly or locally. Signing the key tells your cryptographic software that you’ve validated the other person’s identity and that your software no longer has to warn you that the key has not been properly verified and trusted.Since you have the key ID, the best way to generate the fingerprint, sign, and trust the key is to edit it interactively using a command like:

        gpg --interactive --edit-key keyID

        and then using the commands sign (which will show you the fingerprint, you can also generate it with fpr) and trust followed by save orquit. Hint: Type help for the interactive commands.

      5. If you’ve publicly signed the key, return the signed key to its owner. This allows them to import your signature and share that signature with others. Again, see the Signing a Key section of this document for ways to do this.In some circles, it may be considered more courteous to email the signed key back to its owner rather than to upload the signed key back to a keyserver directly, but be warned that anyone can sign any key and upload it to any keyserver, so someone may do this without your knowledge or consent. In short, exporting the key for e-mailing back to its owner will probably look something like:

        gpg --armor --export keyID

        and then emailing that output to the owner of the key.

        On the other hand, you may not want to send an unnecessary encrypted message, so you can upload the signed key directly to a keyserver using:

        gpg --send-keys keyID

        Again, be warned that the key’s owner and other people will not see or know about that signature until they do:

        gpg --refresh-keys

    • When you receive your own signed key from others, import it. See the detailed steps in the Importing a Key section of the documentation above.
    • Periodically publish your newly-signed key to a keyserver. As you get new signatures, publish them to a keyserver. See the detailed steps in the Publishing your Public Key section of the documentation above. Most people won’t see the new signatures until they’re published to a keyserver!
    • Periodically refresh keys from a keyserver. See the detailed steps in the Updating Keys section of the documentation above to collect all the new signatures from the keysigning party. You may find that other people have signed your key and uploaded them directly to the keyserver. This also helps you collect the web of signatures from all the people who were at the keysiging party.In a nutshell, you can do this with:

      gpg --refresh-keys

    • For fun, look at all your new signatures! You can list the signatures using:

      gpg --list-sigs your@email.address

      If you see signatures that have [User ID not found] you might have better luck examining your key at pgp.mit.edu or sks-keyservers.net.

Technical Notes

The rest of this document contains advanced technical notes. Please send me more.

Short Key IDs Are Bad News

As mentioned above, key IDs are usually specified as 8-character hexadecimal strings. The GPG program makes it sort of hard to see that your full key ID is actually a 16-character hexadecimal string. With only 816 (which is a bit over 4 billion) unique short key IDs, there is a probability that there are collisions of short key IDs in public key servers. That probability is 1, as we know collisions occur. (The probability is infinitesimally close to 1 in mathematical analysis.)

With (at the time of this writing) over 3 million keys in public keyservers, (obtained from the sks-keyservers status pages) there are likely many collisions. One would first expect to see a collision with only about 82,000 keys in the keyserver.

The mathematics of finding the probability of collisions can be found in the Wikipedia Birthday Attack article.

There’s more information in the interesting article Short Key IDs are bad news (with OpenPGP and GNU Privacy Guard) which demonstrates real instances of key ID collisions.

Summary: it’s safer to publish your 16-hex-digit key ID than your 8-hex-digit one. Read on to find out how to find that ID.

Finding Your Longer Key ID

By default, GPG only shows 8-hex-character key IDs when you do something like:

gpg --list-keys eliasen@mindspring.com

pub 4096R/ED873D23 2014-07-22
uid Alan Eliasen <eliasen@mindspring.com<
sub 4096R/5314E70B 2014-07-22

You can change this to get long or short keys using the --keyid-format short|0xshort|long|0xlong option.

gpg --keyid-format long --list-keys eliasen@mindspring.com

pub 4096R/5F2B4756ED873D23 2014-07-22
uid Alan Eliasen >eliasen@mindspring.com>
sub 4096R/11C2E18C5314E70B 2014-07-22

You can get your also 16-hex-character key ID in a more computer-parseable one-line format using the --with-colon option:

gpg --fingerprint --with-colon your@email.com

pub:u:4096:1:5F2B4756ED873D23:2014-07-22:::u:Alan Eliasen <eliasen@mindspring.com>::scESC:
fpr:::::::::EC2392F2EDE74488680DA3CF5F2B4756ED873D23:
sub:u:4096:1:11C2E18C5314E70B:2014-07-22::::::e:

The public key is the line that begins with pub. You can automate the extraction with (on a Linux-like system):

gpg --fingerprint --with-colon email@address.com | grep '^pub' | cut -d: -f5,10

5F2B4756ED873D23:Alan Eliasen <eliasen@mindspring.com>

However, read on to see a more common way to find the 16-hex-character key ID using only the fingerprint.

Key IDs and Hash Algorithms

You might not have noticed that your key ID is the final digits of the fingerprint of your key. It took me a long time to realize that.

A fingerprint is usually the SHA-1 hash of a key, which is 160 bits, or 20 bytes, or 40 hexadecimal characters.

Your short key ID is the last 8 hexadecimal digits of your fingerprint. Your long key ID is the last 16 hexadecimal digits of your fingerprint. So you can always find the long or short key ID if you have someone’s full fingerprint, and use that long or short ID (or the full fingerprint!) to import from a keyserver.

Enigmail, gpg-agent, and Gnome keyring bugs

This section describes workarounds for Fedora Linux (and perhaps other Gnome and Mate environments) where Enigmail apparently remembers passwords forever, even if you don’t want it to.

I noticed that Enigmail never expired my gpg passphrase, even when I told it to expire after 2 minutes of idle time. Even worse, it would then automatically and silently decrypt PGP/MIME messages when I tried to view them, even though I told Enigmail to not automatically decrypt. That’s dangerous. If an attacker adds lot of attachments, they can mount known-cryptext attacks and recover your entire signing key, even with an acoustic attack that never touches your computer!

Update: This is apparently a known bug, Enigmail Bug #287.

I thought this was related to gpg-agent, which sometimes handles passphrase input, so I tried putting the following into a new ~/.gnupg/gpg-agent.conf file to tell it to forget passwords after 60 seconds:

default-cache-ttl 60

However, that didn’t work. I tried switching off “use gpg-agent for passphrases” in the Enigmail advanced preferences, but that didn’t work either.

After further research, I found out that the Gnome and/or Mate desktop environments were setting up their own GPG keyring daemons which just weren’t behaving well. (These processes may be called gnome-keyring-daemon and/or mate-keyring-daemon. Note that this same process name may be controlling your ssh keys as well, so you may not want to kill them outright. Read on.) These can be turned off in Fedora’s main menu by going to System | Preferences | Startup Applications| Startup Programs and unchecking GPG Password Agent: Gnome Keyring: GPG Agent and since I’m running Mate, also unchecking GPG Password Agent: Mate Keyring: GPG Agent. (There are probably lots of other things you might want to turn off in there.)

Enigmail then wouldn’t talk to gpg-agent usefully so I cut it out of the loop also. I disabled “use gpg-agent for passphrases” in the Enigmail advanced preferences. After that, Enigmail popped up its own gpg key dialog, and everything worked just fine, with Enigmail forgetting the passphrase after the specified time.

Note that this may not work just fine if you’re using gpg2, which may require the use of gpg-agent, so you may have to work harder to set that agent up correctly.

Please let me know if you have better workarounds.

Automating GPG

If you’re automating things, you can specify the password for encryption and decryption with the --passphrase password command-line option. Note that the password may get stored in your command history, will be visible in a process list, etc., so this is generally a Bad Idea. You can mitigate this somewhat with the --passphrase-file filename option. Just protect that file! Note: In gpg2 and possibly some versions of gpg, you will have to specify the --batch option for gpg2 to actually use those passwords or passphrases! It doesn’t hurt to specify it in these cases. The --batch option also prevents gpg from popping up a password entry field or anything requiring human interaction.

Signing a key with --sign-key still prompts you if you really want to sign, even with --batch and a passphrase, but you can add the --yes option to automatically choose “yes” to the prompts.

The gpg program usually sends a lot of status information to standard error (stderr) but you might want that output directed elsewhere, or sent to a file. The --logger-file filename or --logger-fd filedescriptor will redirect that output.

For more machine-parseable output, there’s a status file that can be written using the --status-file filename or --status-fd filedescriptor options. This gives lines that indicate details of what was found in the message, what was tried, and the detailed status of each step. More details about this output can be found in the Unattended Usage section of the GPG documentation.

For more fun, here are some Esoteric GPG Options that you may need to know to automate GPG.

Read on to the next section to see how to specify where gpg stores its configuration files and keys.

Making a Sandbox / Multiple keyrings

Often, you’ll want to experiment with GPG without actually making changes to your primary keyring. You can easily create a “sandbox” to make changes to a completely separate keyring. GPG looks at the GNUPGHOME environment variable to see where to read its public and private keys from. (On Linux-like systems this defaults to ~/.gnupg while on Windows it’s stuffed away in the (possibly hidden) directories:

C:\Documents and Settings\username\Application Data\GnuPG
or
C:\Users\username\Application Data\GnuPG
or
C:\Users\username\AppData\Roaming\GnuPG

If you want to make multiple keyrings, set this environment variable before running your gpg commands. (e.g. in a Linux shell,export GNUPGHOME=/directory/of/your/keyring or in Windows, set GNUPGHOME=c:\directory\of\your\keyring and then subsequent commands in that shell will use your “sandbox” keyring.)

Note that gpg will check the permissions on that folder and operations that call external programs (like connecting to a keyserver) will be disallowed if others can write to that directory. In a Unix-like system, you can fix that with:

chmod 700 $GNUPGHOME

For example, you can create a whole new keyring for automated processes:

#!/bin/sh
export GNUPGHOME=/directory/of/your/keyring

# Following commands in this shell will use that home
gpg --import file1

Alternately, you can pass the --homedir dir option to gpg on the command-line with each command.

Forcing Different Algorithms

First, read the Using Stronger Algorithms section above to see how to configure gpg to prefer that people use certain algorithms when sending to you. That section is probably more important than this one. It’s far more important that you and the person you’re talking to use the recommendations in the Using Stronger Algorithms section above.

GPG contains many different encryption and hashing algorithms. You can get a list of the included algorithms with the command:

gpg --version

gpg (GnuPG) 1.4.13
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

When manually encrypting, (either with public-key encryption or symmetric encryption,) you can specify an encryption algorithm with the --personal-cipher-preferences "alg1 alg2..." option and a digest/hashing algorithm using the --personal-digest-preferences "alg1 alg2..." option:

gpg --armor --personal-cipher-preferences "AES256 AES192 AES" --personal-digest-preferences "SHA512 SHA256 SHA1" -rrecipient1@email.address --encrypt filename

You really need to know what you’re doing to use these, though. See the GPG Protocol-Specific Options page for more.

Expert tip: If you really want to force the algorithm used, you can use the --cipher-algo name command-line switch for symmetric or public-key encryption. The --personal-cipher-preferences options above should be used if you don’t want to accidentally violate the OpenPGP specification. You can use the --cipher-algo name argument if you know that your recipient has a modern version of GPG but doesn’t have their public key set up well. Again, encourage them to improve their public key using the Using Stronger Algorithms section above.

Protecting your Secret Keys

Warning: This section is somewhat speculative and may not help you really improve your security against a sophisticated attacker, but may help defeat some threat models.

Your secret keys are, by default, encrypted with older encryption algorithms (CAST5) and hashing algorithms (SHA-1, iterated over 65,536 rounds). You can modify these preferences, though.

You must use a strong password to protect your secret keys. This is the weakest link of your security. If someone is able to obtain your secret key files, they can mount a brute-force attack on it by testing many passwords in a dictionary attack. If you want to make it harder to perform a naïve brute-force attack on your secret keys, you can change the encryption algorithm and increase the number of rounds that are necessary to decrypt and validate your secret key. One way of doing this is to change the password for your secret key with something like the following:

gpg --interactive --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-mode 3 --s2k-count 65000000 --edit-key keyID

and then changing the password using the passwd command, saving/quitting using save and saving the changes.

This forces your secret key to be encrypted with the AES-256 algorithm, SHA-512 hashing, and the mode is iterated and salted. The count means that the hash will be applied 65 million times (which is about the maximum allowed.) This will greatly slow down the decryption of your secret key (it takes about a second on my computer, but that’s rarely a problem,) which might significantly slow down attackers attempting to brute-force your password. Reduce the count if you need to decrypt many messages very quickly, as you will encounter a noticeable delay every time you decrypt a message!

Technical Note: s2k is short for “string to key”. This refers to an algorithm that turns a textual string (i.e. your password) into an n-bit number that can be used as a cryptographic key. (For example, AES-256 requires a 256-bit-long key. Your password is probably not that long, nor evenly distributed bitwise, so these functions try to turn a shorter string into a well-distributed longer key.)

The more expensive that you make attacks on your secret keys, the better. This may not protect you against the highest-level attackers, nor will it prevent attacks directly against the symmetrically-encrypted parts of your message (see the Using Stronger Algorithms section above to improve this,) but it will certainly discourage someone who has obtained your secret keyring and is trying to brute-force the password (say, by using the password-generating features of John the Ripper and passing them into the GPG executable.) This will slow down the speed of password cracking by many orders of magnitude, which is often enough to make brute-force attacks greatly infeasible.

More information at Christopher Wellons’s excellent blog entry.

In the OpenPGP standard, the number of iterations is actually coerced into a single byte, so not all numbers of iterations are possible. Here’s more information about the equation and valid values for --s2k-count.

There is some dispute if these particular options are the best, so do your research. For example, AES algorithms are designed to be fast, so a slower algorithm might actually be better if you’re trying to slow down attackers.

It is also possible that this could weaken your security if the hashing algorithm has fixed points or cycles, that is, values where the input to the hashing function equals the output from the hashing function. Extending the number of iterations may make it more likely that a fixed point or cycle is struck. (Read Donald Knuth’s amusing anecdote about fixed points in his homemade random number generator in Volume 2 of The Art of Computer Programming about how easy it can be to strike fixed points. (Legal links, anyone?)) More research is warranted. Update: I did more research in the technical note below.

Technical Note: I decided to do the math on this, to estimate the probability of a hash cycle or collision with highly-iterated hashing. If we can assume that the output of the hash function is approximately random with respect to the input, (that’s a rather strong assumption,) the mathematics of the problem reduce to an analog to the Birthday Problem (that is, the probability that at least one birthday is shared by at least 2 people in of a group of n people.)

The probability p of a cycle with n iterations and states states in the hash function can be estimated by:

p(n, states) = 1 - e(-n)(n-1)/(2 * states)

Since the argument of the exponent is often a very small number, due to the number of states being very high, (2128 for MD5, 2160 for SHA-1, 2512 for SHA-512,) we will have to use an arbitrary-precision exponential function and extended precision in many environments. Below is a Frink program (a programming language that I wrote) that calculates the probabilities.

use ArbitraryPrecision.frink
setPrecision[200]
p[n, states] := 1 - arbitraryExp[((-n)(n-1)/(2 * states))]

This function can then be called as follows (for the SHA-1 function with 2160 states and 65 million iterations):

p[65 million, 2^160]
1.445e-33

Thus, we can derive the following probabilities of hitting a cycle in various hash functions, assuming they’re close to random:

Hash Function Bits Bytes Cycle probability in 65 million iterations
MD5 128 16 6.2*10-24
SHA-1 160 20 1.4*10-33
SHA-224 224 28 7.8*10-53
SHA-256 256 32 1.8*10-62
SHA-384 384 48 5.4*10-101
SHA-512 512 64 1.6*10-139

Thus, the probability of seeing a random hash cycle with the SHA-512 procedure above are so low (given our assumptions!) that we can estimate that it won’t happen in the lifetime of anyone on the planet living today, and we can proably safely assume that using many iterations, as noted above, will probably improve our security. QED.

Note: I’m also running homemade programs that are attempting to find cycles in iterated MD5 hashes. It builds a giant hash table of the last 100 million hashes it has seen, and will detect any cycle shorter than this. It’s not likely I’ll find one if the hashing function is designed well.

Backing Up Your Secret Key

If, for some reason, you want to back up your secret key and possibly print it, you can use the --export-secret-key --armor option to gpg, possibly using the --output filename option to output to a specified file. Then you could, say, engrave that onto a piece of metal and store it away in a cave for 1000 years. Or whatever. It will be ponderous and error-prone to type that key back in, especially with a large key or a key that contains a photo.

“Creating the perfect GPG keypair”

Warning: Read this whole section before making any decision. This section is actually a warning against these practices, rather than a recommendation.

Alex Cabal has a document entitled “Creating the perfect GPG keypair” (Link opens in new window) in which he describes creating subkeys of your keypair that you can use on a device like your laptop, which somewhat mitigates the risk of your laptop being stolen. In short, it allows you to create a new subkey that is used only for signing, which you keep on that laptop. If the laptop is stolen, you can revoke that signing key which is claimed to prevent the thief from impersonating you. However, I think that this practice is very dangerous, if not outright wrong. There are good tips about managing secret keys in this document, but I argue against its primary premise.

You should be most strongly warned that these practices will leave your communications wide open for interception. The document linked above does not warn youin the strongest possible terms that the practice of creating the “perfect key” lets whoever stole your laptop decrypt and forever continue to decrypt all your email (if they can guess the password used to encrypt your secret key) yet you go on blithely pretending they can’t! That is very poor practice. All that the subkey business does is prevent the attacker from impersonating you by signing messages. (But, again, only if they can guess the password used to encrypt your secret key, and only if your recipients know that you’ve revoked the key.) If they can guess your password, the attacker could still read all your encrypted messages forever. Read on.

Unless everyone that you communicate with regularly does something like:

gpg --refresh-keys

to find out that keys have been revoked, they may never even know that you revoked the signing key, and they will continue to trust your signature.

If the person who stole your laptop (and thus your secret keys) could ever impersonate you (because they guessed the password for your secret key), then they canforever decrypt all the communications sent to you with that same key if you follow the “perfect keypair” advice.

Allowing your attacker to read your encrypted communications forever, and pretending it didn’t happen, is extremely bad and wrong cryptographic practice, obviously. If your decryption key is stolen, revoke that entire keypair and never use any part of it again! Otherwise, your attacker can forever read messages encrypted to your public key.

It appears that the primary benefit of following this procedure is not having to rebuild your web of trust with a new key. However, how much trust should you give to someone who still uses a key that has been knowingly compromised and does not properly protect your communications with them? The answer is none. None more trust.

OpenPGP Specification

For details on the public OpenPGP specification, see RFC 4880.

References: https://futureboy.us/pgp.html

Encrypt / password protect data on Linux with encfs


Encfs – Encrypted file system

We often need to put some confidential data on the hard drive, in which case it becomes essential to have some kind of security mechanism to keep it hidden from unauthorised access of any kind. It could contain credit card numbers, bank statements and list of passwords for various online services.

One way to protect such data with security is to put them in a directory that is password protected or is encrypted. So the encrypted content will need a password everytime to be viewed. Ubuntu comes with a few handy tools to do this, although they are terminal based and will require a bit of effort to setup and use.

Install and setup encfs

The tool is called encfs and is easily installable from synaptic.

$ sudo apt-get install encfs

Once it is installed it will need a minimal setup. Lets say we want to create an encrypted directory called .encrypted inside the home directory whose content shall be available in the directory ‘visible’ upon request. Then run the following command.

$ encfs ~/.encrypted ~/visible

On the first run it will ask a couple of questions like mode and password etc.

$ encfs ~/.encrypted ~/visible
The directory "/home/enlightened/.encrypted/" does not exist. Should it be created? (y,n) y
The directory "/home/enlightened/visible" does not exist. Should it be created? (y,n) y
Creating new encrypted volume.
Please choose from one of the following options:
 enter "x" for expert configuration mode,
 enter "p" for pre-configured paranoia mode,
 anything else, or an empty line will select standard mode.
?> p

Paranoia configuration selected.

....truncated....

New Encfs Password: 
Verify Encfs Password: 
$

Now it is setup and to use it run the same command everytime.

$ encfs ~/.encrypted ~/visible
EncFS Password:

It will ask for the password that was set earlier and upon entering the correct password, the contents of the ‘.encrypted’ directory will be available in the ‘visible’ directory.

Now put all your confidential data inside the visible directory and will be go into the encrypted directory. Once you are done working with the confidential data, simply unmount the visible directory by issuing the following command

$ fusermount -u ~/visible

It will unmount the encrypted directory and all content that was visible in the visible directory will vanish. Rest assured it is there in the encrypted directory and will become available again by running the previous command.

Cryptkeeper

Cryptkeeper is a gui tool that makes the process of mounting and unmounting the encrypted folder a bit easier by providing a taskbar icon. Install it from synaptic.

$ sudo apt-get install cryptkeeper

Now it can be run from “Applications->System Tools->Crytpkeeper” menu in gnome or the K->System->Cryptkeeper menu in kde. Once the taskbar icon comes up left click on it and click “Import EncFS Folder”. Select the encrypted directory and the directory to mount from the popup dialog. Now again left click on the taskbar icon and select the directory to mount it. It will ask for the password and will mount the directory then. To unmound again click the icon and unselect the directory. Simple as that.


How to create password protected zip archive


Command Line

The zip command can be used to create password protected zip files easily. Here is a quick example

$ zip -P *secret* compressed.zip file.txt

Note that the P is capital. Can also type “–password” instead of the “-P”.

$ zip --password *secret* compressed.zip file.txt

The above approach might be a bit insecure since the password is visible and the command is stored in the terminal history and can be retrieved. Another option is the e option which prompts user to enter the password.

$ zip -e compressed.zip file.txt
Enter password: 
Verify password:

The zip utility can be installed on ubuntu through apt-get

$ sudo apt-get install zip unzip

Password protect existing zip files

The above methods work well, but there is an easier way. First create a zip file using any of your favorite gui tools and then password protect it using the zipcloak command.

$ zipcloak confidential.zip 
Enter password: 
Verify password:

This is the quickest method since you don’t have to remember any commandline parameters. Just the name of the command is enough.

Gui

There is a cross platform gui archive manager called Peazip which can be downloaded from

http://peazip.sourceforge.net/

It is probably the most featureful gui archive manager available for Linux. With peazip you do not need the commandline/terminal and everything can be done from the gui interface very much like winzip on windows.