If you’re one of the lucky ones, your ISP might provide native IPv6 connectivity (like [...]]]> IPv6 is nothing new – it was finally standardised back in 1998 in RFC 2460, and virtually all operating systems have supported it now for at least 5 years, so most people are in a position to give it a try.

If you’re one of the lucky ones, your ISP might provide native IPv6 connectivity (like AAISP), but for most of us, the main way to get connected to the rest of the IPv6 Internet is to use something we’ve already got – IPv4. And we’re going to tunnel over it.

The first thing we need to do is choose a tunnel broker, which is a fancy name for someone who’ll provide us with an IPv4 endpoint we can tunnel IPv6 over. Wikipedia has a list, but the main, globally available ones are Hurricane Electric and SixXS. Either of these will do, and some people prefer HE over SixXS, but that’s a purely personal choice – in my experience, both work equally as well. For this example, though, we’ll go with HE – so head on over to http://tunnelbroker.net/ and create an account.

My first tunnel

Once you’ve created your account, log in and create a tunnel. For some reason, it always seems to pick their New York POP, so you might want to manually choose one geographically closer (in my case – and for our example – London, UK)

Creating a tunnel

The IP address you use as your local end of the tunnel will need to be a public IP address. It’s possible to use a machine behind a NAT device if it’s in a DMZ-style setup where all the traffic destined for the public IP address gets forwarded by the NAT device to the machine behind it, but your mileage may vary.

Once created, view the tunnel details, which should look something like this:-

Editing the tunnel details

Our tunnel has been created! At the bottom of the page, you’ll notice a little drop-down that generates the commands needed to bring up the tunnel. For this example, we’re using iproute2, so the commands go something like this:-

ip tunnel add he-ipv6 mode sit remote 216.66.80.26 local 192.0.2.1 ttl 255
ip link set he-ipv6 up
ip addr add 2001:470:1f08:810::2/64 dev he-ipv6
ip route add ::/0 dev he-ipv6

The first command creates an IPv6-in-IPv4 tunnel between us and HE, and the second command brings up that tunnel. The third command adds our IPv6 address to our end of the tunnel, and finally the fourth command sets the IPv6 default route to be down our newly-created tunnel.

And that’s it – we’re now connected to the global IPv6 internet. To test it, let’s try pinging something:-

mordor:~# ping6 -c 3 www.he.net
PING www.he.net(he.net) 56 data bytes
64 bytes from he.net: icmp_seq=1 ttl=58 time=375 ms
64 bytes from he.net: icmp_seq=2 ttl=58 time=257 ms
64 bytes from he.net: icmp_seq=3 ttl=58 time=255 ms

--- www.he.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 255.562/296.218/375.628/56.158 ms

If you see something like the above, then give yourself a pat on the back, because it’s working!

Next steps

HE by default assigns you a /64 network, which is the smallest size intended to be allocated. This gives you 18,446,744,073,709,551,616 IPs, and whichever way you look at it that’s a lot of addresses. With this in mind, you might be wondering why HE will give you a /48 (that’s 1,208,925,819,614,629,174,706,176 IPs!). The reason is that each network is intended to have a /64, and a /48 allows you to carve up that space into a total of 65,536 separate /64 networks. Now this obviously sounds like overkill to the average user, but autoconfiguration tools such as radvd won’t work with networks smaller than /64, again because of the intentions mentioned previously. This means that if you have more than one network at home (say, a wired network and a wireless network, currently with separate IPv4 networks for each), you can assign a /64 to each one.

With this is mind, let’s ask HE for a /48 by clicking on Allocate in the ‘Routed /48′ section. After a few seconds, you’ll see something like this:-

Allocating our /48

In our example, we’ve been allocated 2001:470:90d3::/48, and now it’s time to plan our IP schema.

Laying it out

Taking my own home network as an example, I have three networks – one for general use (the ‘LAN‘), one for guest use over wireless (the ‘WLAN‘), and finally a DMZ (the… er, ‘DMZ‘). We could lay these out like this:-

• LAN – 2001:470:90d3:1::/64
• DMZ – 2001:470:90d3:2::/64
• WLAN – 2001:470:90d3:3::/64

Nice and simple, and easy to remember. Assuming all three networks are connected to the same gateway machine, we can give the gateway the first IP in the range – 2001:470:90d3:1::1, 2001:470:90d3:2::1 and 2001:470:90d3:3::1.

Routing things further

Before we start, we need to enable IP forwarding for IPv6:-

sysctl -w net.ipv6.conf.all.forwarding=1

You’ll probably want to add this somewhere so it gets activated on bootup – under Debian this would be in /etc/sysctl.conf (which already has the entry, albeit commented out).

One way to provide connectivity to machines on the individual networks is to manually give each machine an IPv6 address, and to route it through our gateway:-

ip addr add 2001:470:90d3:1::2/64 dev eth0
ip route add ::/0 via 2001:470:90d3:1::1 dev eth0

Again, all being well, you should now be able to route to the wider IPv6 Internet from our newly-configured IPv6 node. More importantly, this also means that the wider IPv6 Internet can route back to you – which brings us to…

Security, not obscurity

Don’t be fooled into thinking that because of the immense range of possible IPv6 addresses that securing your new IPv6 setup isn’t required – IPv6 is no exception when it comes to the Internet Bad Guys, so implementing firewall rules is of the utmost importance.

The problem with IPv4 and NAT is that it’s allowed people to become somewhat complacent about security, because machines behind a NAT device are naturally unreachable from the global Internet. IPv6 does not have NAT, which means you don’t have this (rather lazy) safety net, so we have to do it properly.

Luckily, if you’re familiar with iptables, you’ll be glad to know that there’s an IPv6 equivalent – and it’s called (predicatably) ip6tables. The syntax is identical, and in fact the only noticeable difference is that you’re using IPv6 addresses and networks instead of IPv4 ones.

A quick example would go something like this:-

# Clear our INPUT, OUTPUT and FORWARD chains
ip6tables -F INPUT
ip6tables -F OUTPUT
ip6tables -F FORWARD

# Allow packets related to existing connections
ip6tables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow link-local (for neighbour discovery)
ip6tables -A INPUT -s fe80::/10 -j ACCEPT

# Allow SSH inbound to our gateway from our LAN
ip6tables -A INPUT -i lan -s 2001:470:90d3:1::/64 -p tcp
   -m tcp --dport 22 -j ACCEPT

# Allow all outbound from our networks
ip6tables -A FORWARD -i dmz -s 2001:470:90d3:1::/64 -j ACCEPT
ip6tables -A FORWARD -i lan -s 2001:470:90d3:2::/64 -j ACCEPT
ip6tables -A FORWARD -i wlan -s 2001:470:90d3:3::/64 -j ACCEPT

# Allow all outbound from our gateway
ip6tables -A OUTPUT -j ACCEPT

# Allow SSH and HTTPS inbound to our DMZ
ip6tables -A FORWARD -i he-ipv6 -d 2001:470:90d3:1::/64 -p tcp
   -m multiport --dports 22,443 -j ACCEPT

# Set the default policy to drop
ip6tables -P INPUT DROP
ip6tables -P FORWARD DROP
ip6tables -P OUTPUT DROP

So there you have it – IPv6 firewalling needn’t be difficult. If you want to make something more complex, you might want to take a look at my previous post about iptables and the ‘mark’ target, which also applies to ip6tables.

IPv6 – automatically

Just like DHCP for IPv4, there are autoconfiguration mechanisms for IPv6 – radvd and DHCPv6. Radvd is the older of the two, but both can be used for the same purpose. Configuration of radvd is relatively straightforward, and if we wanted to provide autoconfiguration on our example LAN, we can do something like this:-

interface lan
{
      AdvSendAdvert on;
      MinRtrAdvInterval 3;
      MaxRtrAdvInterval 10;
      AdvDefaultPreference low;
      AdvHomeAgentFlag off;

      prefix 2001:470:90d3:2::/64
      {
            AdvOnLink on;
            AdvAutonomous on;
            AdvRouterAddr off;
      };
};

Where next?

This only covers the start – there’s more involved in bringing an IPv6 network up to scratch, like setting up forward and reverse DNS, and configuring various daemons to talk over IPv6 as well as IPv4. If you’re interested, you might find some of the following links useful reading:-

• Peter Bieringer’s Linux IPv6 Howto
• IPv6 in the UK
• RFC 2460 – IPv6 Specification
• Deep Space 6

I’m not a mathematician (or a cryptographer) so I’m happy to take this post‘s word for it about a recent attack against SHA-1 (short PDF here). The post goes into detail about changing the [...]]]> (Note: This was originally posted on my previous blog, but I’ve noticed that it’s being linked to, so I’ve reposted it here)

I’m not a mathematician (or a cryptographer) so I’m happy to take this post‘s word for it about a recent attack against SHA-1 (short PDF here). The post goes into detail about changing the preferred digests on a key, and is well worth a read.

The post also talks about using 2048-bit RSA keys, instead of the DSA/Elgamal default (which has a maximum size of 1024 bits). It goes into detail about how to migrate to an RSA key – if you’re going to migrate, I definitely recommend reading it.

However, I thought it would be nice to write a (very) quick guide on generating RSA private keys with GnuPG, as there are a few extra steps involved – but nothing complicated!

Preparation

The first thing mentioned in the post on Debian Administration is to set a couple of GnuPG config options to ensure that any digests generated by you are using the stronger SHA256, rather than SHA-1. Doing this is simple:-

cat >>~/.gnupg/gpg.conf <<EOF
personal-digest-preferences SHA256
cert-digest-algo SHA256
EOF

We’re now ready to generate our key.

Generate our first key

To start with, start the key generation as normal:-

[andys@sirius ~]$ gpg --gen-key
Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)

(1) is the default, and generates a DSA key with an Elgamal subkey for encrypting. But for our RSA key, we need to choose (5).

Next, we’re asked for our key length. This is between 1024 and 4096 bits. The default is 2048, but for mine I’ve chosen 4096. A good overview of keys and key sizes can be found on pgp.net here.

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits

The next question is about how long you want the key to be valid. Again, this is personal preference, and in this instance I’ve chosen ’0′ for ‘never expires’:-

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) 0
Key does not expire at all
Is this correct? (y/N) y

Next up is your user ID, which consists of your name, e-mail address and a comment. I tend to leave the comment field blank, but it’s there if you want it:-

You need a user ID to identify your key; the software constructs the
user ID from the Real Name, Comment and E-mail Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Andy Smith
E-mail address: andy.smith@netprojects.org.uk
Comment: [Return]
You selected this USER-ID:
    "Andy Smith <andy.smith@netprojects.org.uk>"

Change (N)ame, (C)omment, (E)-mail or (O)kay/(Q)uit?

Select ‘O’ to continue.

You need a Passphrase to protect your secret key.

You’re now being prompted to set a passphrase on the key. This can be as strong or as weak as you like, but considering the importance of your private key it’s best to secure it with a strong passphrase.

After supplying a passphrase, the actual key will be generated. RSA keys require quite a bit of entropy (‘randomness’), and you’ll probably get a warning like this:-

Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy!  (Need 284 more bytes)

A good way to generate entropy is to create lots of I/O traffic (keyboard, mouse, network, disk, etc.). I found using cat(1) on files and redirecting the output to /dev/null worked quite well, especially if you use a block device of some sort (for example, I did cat /dev/sdb >/dev/null, where /dev/sdb was a 1GB USB key).

Eventually – hopefully after not too much of a wait – gpg will report that it has completed generating the key, and you’ll have output a bit like this:-

gpg: key A0E6B93E marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
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
pub   4096R/A0E6B93E 2009-05-08
 Key fingerprint = B2C5 59E3 E685 757A 45CD  7760 5BF3 1276 A0E6 B93E
uid                  Andy Smith <andy.smith@netprojects.org.uk>

Note that this key cannot be used for encryption.  You may want to use
the command "--edit-key" to generate a subkey for this purpose.

The key ID is now given, which in this case is A0E6B93E. We can also see (on the line that starts with ‘pub’) that the key is 4096 bits in size, and is an RSA key (denoted by the ‘R’). Sharp-eyed readers may have noticed that the key ID is actually the last 8 bytes^[1] of the key’s fingerprint – this is because the key ID is just a shorter way of expressing the key fingerprint, and in itself isn’t guaranteed (or indeed intended) to be unique.

Also important is the last two lines, which point out that our brand spanking new key can’t be used to encrypt anything just yet.

Adding encryption

So without further ado, let’s create a subkey that lets us do encryption with our key:-

[andys@sirius ~]$ gpg --edit-key A0E6B93E
<...version information...>

Secret key is available.

pub  4096R/A0E6B93E  created: 2009-05-08  expires: never
  usage: SC
 trust: ultimate      validity: ultimate
[ultimate] (1). Andy Smith <andy.smith@netprojects.org.uk>

Command>

Unsuprisingly, ‘addkey’ is the command we want to generate a subkey, so that’s what we’ll run. Upon hitting enter, you’ll be prompted for the passphrase you set on your key earlier. Once given, you’ll be presented with a menu like this:-

Please select what kind of key you want:
 (2) DSA (sign only)
 (4) Elgamal (encrypt only)
 (5) RSA (sign only)
 (6) RSA (encrypt only)
Your selection?

Since it’s to complement our existing RSA key – which can already be used for signing – (6) is the option we want. Picking it brings us to a familiar prompt, wherein we’re asked for a key size:-

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096

The subkey’s size doesn’t have to match that of the parent key, but in this case I’ve gone for the same size, so 4096 it is. After picking a size, you’ll again be asked how long you want the key to be valid for. I’ve gone for 0 again, but again it doesn’t have to match that of the parent key. There is a slight difference, in that you’ll be prompted twice, just to make sure that you want to create the subkey:-

Really create? (y/N) y

Now it’s time once more to play the entropy game. Use whatever you found worked for you earlier, and eventually you’ll see something like this:-

pub  4096R/A0E6B93E  created: 2009-05-08  expires: never
  usage: SC
                     trust: ultimate      validity: ultimate
sub  4096R/5D0CCD64  created: 2009-05-08  expires: never
  usage: E
[ultimate] (1). Andy Smith <andy.smith@netprojects.org.uk>

As you can see, I now have a subkey with a fingerprint ending in 5D0CCD64, which can be used for encryption – denoted by the ‘E’ at the end of the line. Also noted is that the key is ‘ultimately trusted’ by me, because it’s been added as a subkey to my key.

Changing the digest settings

As per the post linked to at the beginning, we can change the digest (or ‘hash’) that we prefer to receive signed data in. Without going into too much detail (you should read the post!), we can change these preferences:-

Command> setpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES
  CAST5 ZLIB BZIP2 ZIP Uncompressed

Our preferences are confirmed back to us, and we’re asked to accept them:-

Set preference list to:
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y

Confirming our changes

Since we’re now finished, we need to save the key to confirm our subkey:-

Command> save
[andys@sirius ~]$ _

At this point, the key can now be used for signing and encryption. You can do other things, such as add a small photo to the key using the ‘addphoto’ command, but two things you should do are to publish the key to a keyserver, and to generate a revocation certificate.

Publishing your new key

I won’t dwell too much on details, but in brief keyservers are exactly what they sound like – they serve keys out to users. Submitting your key to a keyserver allows other people to search for and download your public key from a keyserver. This saves you having to send a copy to everybody who wants it, for one.

Submitting is simple:-

[andys@sirius ~]$ gpg --keyserver keys.gnupg.net --send-key A0E6B93E
gpg: sending key A0E6B93E to hkp server keys.gnupg.net

Providing there are no errors, your key has been submitted to the keyserver at keys.gnupg.net.

Revocation

There’s a few reasons why you may no longer wish to use a key. It might have been compromised by a 3rd party, or it might simply be that you’ve forgotten the password. That’s why it’s a good idea imperative that you generate a revocation certificate and store it somewhere safe and inaccessible to everyone but you! A revocation certificate allows the holder of the certificate to revoke your key, and ideally the holder will be you and only you.

To generate a revocation certificate:-

[andys@sirius ~]$ gpg --gen-revoke A0E6B93E >A0E6B93E-rev.asc

This then gives us:-

sec  4096R/A0E6B93E 2009-05-08 Andy Smith <andy.smith@netprojects.org.uk>

Create a revocation certificate for this key? (y/N) y

After answering in the affirmative, you’ll be prompted for a reason why you want to revoke the key. In my case, I’m going to choose (3), as the key was created for the purposes of this demonstration, but as you can see there are a number of other options to choose from:-

Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 3

You can now enter a description, which is fairly obvious:-

Enter an optional description; end it with an empty line:
> Demonstration
> [Return]
Reason for revocation: Key is no longer used
Demonstration

Is this okay? (y/N) y

Answer yes, and you’ll again be prompted for your passphrase:-

You need a passphrase to unlock the secret key for
user: "Andy Smith <andy.smith@netprojects.org.uk>"
4096-bit RSA key, ID A0E6B93E, created 2009-05-08

ASCII armoured output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print
system of your machine might store the data and make it available to
others!

At this point, you now have a revocation certificate in A0E6B93E-rev.asc. If you want to revoke this key now (which we do), then import it. It’s important to note that you don’t import the revocation certificate until you actually want to revoke the key. Anyway, here’s how:-

[andys@sirius ~]$ gpg --import <A0E6B93E-rev.asc

You won’t be asked to confirm this action, and you’ll immediately see the following:-

gpg: key A0E6B93E: "Andy Smith <andy.smith@netprojects.org.uk>" revocation certificate imported
gpg: Total number processed: 1
gpg:    new key revocations: 1
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

This indicates that the key has now been revoked, which we can check by typing:-

[andys@sirius ~]$ gpg -k A0E6B93E
pub   4096R/A0E6B93E 2009-05-08 [revoked: 2009-05-08]
uid                  Andy Smith <andy.smith@netprojects.org.uk>

All that remains is for us to repeat the process we used earlier to submit our key to the keyserver, which this time will send the revoked version of the key:-

[andys@sirius ~]$ gpg --keyserver keys.gnupg.net --send-key A0E6B93E
gpg: sending key A0E6B93E to hkp server keys.gnupg.net

Our key will now appear to be revoked to anyone who looks for it.

Summary

That should just about cover the basics of generating an public/private RSA key pair with GnuPG. There’s a lot more that can be done with it, and having a good read about cryptography in general will help you get your head around some of the fruitier bits.

[2] – Thanks also to Tom, who pointed out that both myself and Tero were wrong – it’s the last 4 bytes. I might give up now

Further reading

Thanks to Daniel Kahn Gillmor for his article ‘HOWTO prep for migration off of SHA-1 in OpenPGP‘, which details the digest steps above and was the inspiration for this article. Thanks also to Martin Krafft for his post ‘The need for a GPG revocation certificate‘.

• The comp.security.pgp FAQ – http://www.pgp.net/pgpnet/pgp-faq/
• HOWTO prep for migration off of SHA-1 in OpenPGP (Daniel Kahn Gillmor / Debian Administration)
• The need for a GPG revocation certificate (Martin Krafft)
  
• Pretty Good Privacy (Wikipedia)

Unfortunately, the openssh-client package from Debian (and Ubuntu) doesn’t [...]]]> I’m using OpenSC at the moment so that I can repurpose an otherwise unused Aladdin eToken to hold SSH keys. I could go through the process involved in setting up the token, but as this chap has already done a thorough job, I won’t go into detail.

Unfortunately, the openssh-client package from Debian (and Ubuntu) doesn’t enable OpenSC support. It’s trivial to rebuild the package with OpenSC support, but for those who don’t want to or can’t for some reason, I’ve put my rebuilt, OpenSC-enabled packages here.

Once installed, if your token is set up correctly, you should be able to get your SSH public key from the card with:-

ssh-keygen -D <card>

…which should give you something like:-

ssh-rsa AAAA .. .. .. t8/Q==
1024 65537 14233 .. .. .. 70941

You can then add your private key to a running SSH agent with:-

ssh-add -s <card>

Pop in your PIN, and ssh should function as if you were using a normally-generated key.