Advertisements
Raspberry Pi Powered OpenVPN – Client Side
19 Apr

Raspberry Pi Powered OpenVPN – Client Side

This is part two of my series on creating your own, private, VPN server at home using a Raspberry Pi. If you have followed on from my Raspberry Pi Powered OpenVPN – Server post you will have a fully working OpenVPN server. You probably also noticed it took you a good portion of your afternoon, but with bugs and hacks being found in more and more Linux software and libraries it is well worth having a server you can trust.

You’ll have noticed though we’re missing a vital step before we can make use of our new server. In part three of my tutorial we created some access keys to allow our phones and laptops (from here on called clients) to access our server, but we haven’t told the clients.

OpenVPN software gets all the information about where your server is, how to connect, what keys to use and what connections to create from a configuration file called and .ovpn. Since you need a separate OVPN file for each client we’ll use a script to do our heavy lifting.

Eric Jodoin first created this script while at the SANS institute, and with some basic template files, it can create configuration files for all our clients.

As with the Raspberry Pi Powered OpenVPN – Server tutorial the following commands still need executed as root, so remember ether add sudo infront of them or make sure you still have root from the sudo -s command.

Setting the defaults

Eric’s script works by combining a default configuration file with the keys specific to client, so we need to create it first.

Create a new blank file:

nano /etc/openvpn/easy-rsa/keys/Default.txt

Then copy and past in this:


Remember to change the line remote to match your setup. Include the public IP address of your OpenVPN server and make sure the port and proto are correct. If in on page four you opted to use TCP or a non standard port, one other than 1194, you need to make sure this is correct here as well.

If you are not sure what your public IP address is you can ask Google.

Some ISPs will rotate your IP address regularly which causes a problem when trying to access your new server. There are however many services that offer dynamic domain names (DDNS). These give you a static domain name but make sure the IP address always points to your home PC. First thing I would do is check your router to see if it supports a DDNS provider. If it doesn’t then you can use a free service like DNS Dynamic, but you will have to setup and run the ddclient on the Pi to keep your IP address updated.

As in the previous tutorials use control+x and save the new file.

Creating the script

Now we’ll create a copy of the script Eric produced, the original PDF download of his research paper can be found online.

First create a new file in nano:

nano -w /etc/openvpn/easy-rsa/keys/ovpn_gen.sh

Get a copy of the script from my gitlab server and past it into this new file. Lastly control+x and save the new script.

By default new files created in nano are just text files, they do not have permission to execute commands. This command will give only the root user permission to read, write or execute our new file:

chmod 700 /etc/openvpn/easy-rsa/keys/ovpn_gen.sh

We can now run the script, but first make sure we are in the keys folder:


The first thing we’re asked for is the Client Name. This must be the same as we used in page three of the server side tutorial. I’ll continue using KEYNAME here, but if I was setting up the key for my Nexus 5 I would use stuart.nexus5.

If everything worked as expected you’ll see a message like this:


Now just rinse and repeat for as many clients as you have setup, but make sure to only run the command for keys you already created. If you need a new device go back to page three and create a new set of keys first.

Downloading the OVPN files

You now have to download your new OVPN file from the /etc/openvpn/easy-rsa/keys/ folder onto your clients. If you are on a link system I would use the scp command, but for Windows users WinSCP would work as well.

If you are using WinSCP you will not have permission to access the /etc/openvpn/easy-rsa/keys/, this is by design and adds additional protect to your server. So you can cp the file into the pi home directory first and download it from there, but make sure to delete it once you have it on the client.

cp /etc/openvpn/easy-rsa/keys/KEYNAME.ovpn /home/pi/

and then

rm /home/pi/KEYNAME.ovpn

In part two of this tutorial we’ll take a look at setting up our client and getting OpenVPN installed and running on your Android phone or tablet.

The Dangers of Open Spots
01 Feb

The Dangers of Open Spots

All over the web you will see people telling you the internet is an unsafe place to be, but the biggest danger doesn’t come from some one sitting at home intercepting your connection to your bank or Facebook. It comes from someone sitting in the same coffee shop as you getting between you and the internet, what’s known as a ‘man-in-the-middle-attack’.

This illustration shows what a normal Internet connection should look like:

Standard Internet Connection

As you can see the green and red lines represent unchanged traffic between you and the internet.

But in a man in the middle attack it would look more like this:

Man-In-The-Middle Connection

In this case you are sending traffic to a third party, connected to the same router as you, and they are sending that on to the internet. They receive a response back and forward that on to you. This allows them to rewrite any web page or email before you see it and they can see any passwords you are sending.

Having an HTTPS connection can go along way to protect yourself from this kind of attack but it’s not perfect. If a man in the middle can intercept all your traffic they can intercept your connection request offer you a secure connection with them and create a secure connection to the remote host.

SSL Certificate Shield This is part of the reason we use Certificate Authorities. While the man in the middle can offer you a secure connect to their fake site, they can’t fake the signature. So if everything is working correctly your browser will throw up an error an encourage you to click away, but as users we’re trained to push past these without ever reading them or paying attention.

Another way this fails is when a certificate authority, whom your browser trusts, looses control of their keys. In effect a hacker can now create fraudulent certificates for any site they like and your browser will accept it quite happily. At least until everyone updates their browser.

There are a number of solutions to this each with its ups and downs. The one the industry is favouring is EV certs. These are special certificates that in most cases turn your browsers address bar green.

It’s important to understand what this EV certs actually does. It is cryptographically no more secure than a self signed certificate but it has better authenticity. Before any certificate authority can issue you with an EV certificate they have to perform far more checks on who you are, and that’s what you pay for.

A regular certificate lasting one year will separate you from between £9.99 and £175.00 of you hard earned cash but an EV certificate for the same twelve months would set you up back £249.99 and £1000.00.

While EV certificates are a solution, and a good one, they still rely on the website you’re visiting doing the hard work, and paying the fee. So we need to look at more practical solutions a user can do.

One of the best, and easiest, is only accessing the internet from a trusted router. So you can stop using any public wifi, easy. A slightly less extreme way would be if we could access the internet from our home router all the time, from where ever we are.

Raspberry Pi So how do we access the Internet from home when we’re in a coffee shop on the other side of the city? Like everything there are lots of solutions but the main one would be a VPN, like OpenVPN. Like all servers you have to be running it on your home machine at all times, just in case you want to connect to it. Not cost effective and a waste of electricity, but we can use a cheaper form of computer like a Raspberry Pi, I’ve already posted about the running costs of a Pi but it’s usually in the region of £4.60 to £10.52 per year.

This is the solution I’ve decided to go for since its open source and supports all versions of Linux, Windows and even had an Android app.

In the next article I’ll start by talking you through the initial setup of the Raspberry Pi then we’ll move on to installing OpenVPN and finally getting your laptop and Android connected.

TrueCrypt
29 Nov

TrueCrypt

TrueCrypt is dead, long live TrueCrypt. In a move that shocked everyone on the internet TrueCrypt was taken down on May 28th 2014 and the official TrueCrypt website, truecrypt.org, began redirecting users to a page warning the software contained unfixed security issues.

This announcement caused a great amount of panic and speculation about one of the most popular cross platform encryption tools available. As the dust settled it’s become clear there are no known security problems with TrueCrypt but all development by the original authors has ceased and it is their opinion that to use unmaintained software would pose a security risk.

Don’t Panic

In part they might be right. If down the line a flaw in TrueCrypt is found they will not be fixing it, but as yet there is no such flaw and a full security audit is under-way. The audit is being carried out by iSECpartners and crowed funded by TrueCrypt users. While still in its infancy it has already completed work on the TrueCrypt boot loader and found nothing of concern. For those who don’t want to read the full report Steve Gibson of GRC.com did a fantastic breakdown for Security Now Episode 458.

Verifying the TrueCrypt v7.1a Files

Across this site I have used my OpenGPG key to digitally sign my downloads as a way of authenticating them. In this case I didnt want to sign the work of someone else and it would only have verified that the download was the one I intended for you to get.

Since paranoia is nothing to be ashamed of I’ve taken a leaf out of GRC’s book and provided SHA256, SHA1 and MD5 hashes for all my downloads which I have then digitally signed to prevent tampering.

Now, since I do not have another site I can host an independant copy of these hashes on I can only point you to the same place as GRC does. Taylor Hornby (aka FireXware) of Defuse Security is hosting a copy of the same files offered by GRC at https://defuse.ca/truecrypt-7.1a-hashes.htm. The best validation I can offer is the hashes of my files match exactly what is offered by GRC and serveral other independent archives.

TrueCrypt 7.1a Archive Repository

File Name Operating System
truecrypt-7.1a-linux-x64.tar.gz Linux/Unix [Download not found]
truecrypt-7.1a-linux-x86.tar.gz Linux/Unix [Download not found]
TrueCrypt 7.1a Mac OS X.dmg Mac OS X [Download not found]
TrueCrypt Setup 7.1a.exe Microsoft Windows [Download not found]
TrueCrypt User Guide.pdf N/A [Download not found]
truecrypt-7.1a-linux-console-x64.tar.gz Linux/Unix [Download not found]
truecrypt-7.1a-linux-console-x86.tar.gz Linux/Unix [Download not found]
TrueCrypt 7.1a Source.tar.gz N/A [Download not found]
TrueCrypt 7.1a Source.zip N/A [Download not found]

OpenPGP Signed Download Hashes

OpenPGP: How I Sign Keys
11 May

OpenPGP: How I Sign Keys

Signing is a very personal thing. You are telling the world you believe a key belongs to the person who is claiming it. The value of a web of trust comes from the fact you are willing to put your reputation behind this assertion.

Everyone will treat signing differently. Some may feel bumping into someone at a conference is sufficient, other may want a full DNA breakdown with supporting evidence from three expert witnesses. I like to think I’m somewhere in the middle and have documented my signing policy. This page is about how I sign a key and what you need to do next.

Prerequisite

In order to sign a key you need the master key, and as detailed in my key creation guide I keep my master key separate from my normal key store, so can not do any signing during events. Instead I sign all keys at home then get the signed public key back to you for you.

The Act

Like all repetitive tasks I have created a script for that which you can download from its project page. The script does five things:

  1. First download the key to be signed into my keystore
  2. Sign all key identity’s associated with that key
  3. Export the signed public key
  4. Encrypt it
  5. Finally the script deletes the signed public key from the keystore and re-download the unsigned version from the public key

Next

Now I have an encrypted file containing your key I have just signed, but I do not have a signed copy in my key store. My preferred way of getting a signed key to you is by email. Since I have encrypted the signed file you have to have access to the private key and email address in order to use it and I feel this adds a level of additional verification that you really do have control of the key I just signed, after all there are many reasons you might not – I mean I could have just signed the wrong key.

You have noticed my bash script now leaves without a signed copy for you key, this was a deliberate step. I said above by emailing you I am able to assure myself I have not only signed the right key but you have access to the correct email box. Once you import the key and push it back out to your key server I will retrieve a copy from there.

What do you do now?

If you receive a signed key from me you simple need to run the following command:

PGP will ask for your password and import the new signed key and verify the attachment was signed with my primary key fingerprint: BB2C EB25 BE05 16A7 A9C6 F2FB EEB4 96E6 1FA1 E814. It is now up to your to send your newly signed key back to a server for the rest of the world to see.

OpenPGP: My Keys
03 May

OpenPGP: My Keys

Its May again and the sun has finally made an appearance. With summer comes the regular spring clearing and it seems as good a time as any to update my public encryption keys. My previous keys were cryptographically less secure, 2048-bit compared to 4096-bits. I have also learnt allot more about best practices when managing keys and feel its about time to put everything I’ve learnt into affect.

My Secondary key 0xB784045B remains the same. This key was and has always been stored off line in a TrueCrypt volume using a 4096-bit key so I always have been, and still remain, confident about its security. I am replacing my Primary key using the full key creation and cross signing guide. This new key is also covered by my signing policy.

My OpenPGP Keys

Bellow is listed my current PGP keys including my Primary-key and Secondary-key. The Key id is a short identifying mark for all keys. It is made up of two components separated by a slash. The first identities the strength and algorithm of the key, so 4096R means its a 4096-bit RSA key. The second is the last 8 digits of the key fingerprint. These are the short form of identification. The keys full identification is its fingerprint, 40 hexadecimal digits.

The key also publishes its creation and expiry dates. All my keys will expire – encase of loss or compromise – however it is my intention to continue extending the expiry date for as long as I feel confident of their security.

Primary OpenPGP Key

0x1FA1E814

The key mentioned bellow (and on /about/me) is my main key, for every day use. It can be considered acceptably-safe, as I take grate care in assuring it remains that way. However, since it is my main key it has to be store on other devices such as laptops, mobile phones and tablets. This opens the key to danger from theft.

Following the advice in the Debian Subkeys wiki I have created separate subkey for signing. This mean the key stored on my devices does not contain the master key – this is stored separately on a TrueCrypt volume in an offline laptop which doesn’t leave the house. Key signing is still done using the master key which means I can not do it during any key-signing events, I have to do it once I get home again – See my full key-signing policy for how I manage this.

The most recent version of this keys is available from the key server at sks.research.nxfifteen.me.uk or for PGP Key: 0x1FA1E814 (67 downloads) , it is also returned by my DNS server. If you issue the command dig +short stuart._pka.nxfifteen.me.uk. TXT the returned key should match that provided here.

If there ever comes a time when I can no-longer assure my self of this keys security/integrity I have revocation certificates stored in a number of safe locations.

pub 4096R/1FA1E814 Created: 2014-05-04
Key fingerprint = BB2C EB25 BE05 16A7 A9C6 F2FB EEB4 96E6 1FA1 E814

SmartCard OpenPGP Key

0xB7266A16

The most recent version of this keys is available from the key server at sks.research.nxfifteen.me.uk or for PGP Key: 0xB7266A16 (57 downloads) .

If there ever comes a time when I can no-longer assure my self of this keys security/integrity I have revocation certificates stored in a number of safe locations.

pub 2048R/B7266A16 Created: 2014-05-04
Key fingerprint = 0E06 2B0D 4E2D BE43 29B9 1C01 9FCD F90A B726 6A16

Secondary/Alternate OpenPGP Key

0xB784045B

A second key is also available, which can be considered extremely-safe and is never stored on any computer (the keys are located on a TrueCrypt protected USB drive stored in a safe location) or ever been transmitted over the any internet connections, so please be patient if you requires a reply.

This keys is available from the key server at sks.research.nxfifteen.me.uk or for PGP Key: 0xB784045B (55 downloads) .

For verification purposes my other keys is always cross-signed with my secondary key.

Feel free to use the following public key if you are concerned or paranoid about what you wish to send to me, however if you are in doubt you should probably use my primary key instead.

pub 4096R/B784045B Created: 2011-09-19
Key fingerprint = 2642 7F79 DA14 44C4 CBE9 23BB 22C7 2B37 B784 045B

Chairman of The Software Society OpenPGP key

0x69AA4946

Since April 2012 I have held the position of Chairman of The Software Society Ltd. On the 23th of March this year, 2013, it was decided that the board of directors and office bares (Chairman, Company Secretary and Chief Financial Officer) should all create an use OpenPGP keys for all official business.

It was also decided that each office barers key should last as long as they are in office, the new incumbent creating a new key apon their election.

To this end, during my time in the post my key will be 0x69AA4946 and will be subject to the same signing policy as I has been in use on my personal key.

pub 2048R/69AA4946 Created: 2013-03-24
Key fingerprint = CFAE 70BC 1735 BF50 C993 DACB 6415 6795 69AA 4946

Retired Keys

I have been using PGP on and off since about 2008, in that time many keys have come and gone and I did not set expiry dates on most of them and never thought to generate or use revocation certificates. The nature of OpenPGP and the Web-of-Trust means there is no way retrospectively to remove these keys. The best I can do now is list them here. Do not use any of the keys listed bellow. This is not a complete list, only the ones I can no longer revoke.

0x5DCC0296, 0x541784DD, 0x132DED8D, 0xC5751341, 0xCB52DED2, 0xC941927D, 0xDFA274F2, 0x9F9A8CE0,0x2DF1892D, 0x843D80BA, 0xA7EEB609

OpenPGP: How does PGP work?
03 May

OpenPGP: How does PGP work?

How does it work

The magic, and I call it magic because I freely admit I do not have the mathematical background to explain it better, of this system is that if you encrypt something using the Public-key only the Private-key can decrypt it and vice versa. So there is no way for someone holding the Public-key to decrypt something encrypted using the Public-key, only the Private-key will decrypt it. The same is true in reverse. If something is encrypted using the Private-key only the Public-key can decrypt it again – in practice you won’t have a problem here, because if you hold the Private-key you already hold the Public-key as well.

Now when I write an email and want to sign it PGP looks at the message or file (for simplicity I’ll stick to email as my example) then runs a mathematical hash such as SHA256. A hash is a one way process. If you hash a block of text, using SHA256, you will get a string of what appears to humans as gibberish. The important part is, it is always the same. No matter how many times you run the same block of text through the SHA256 algorithm you will always get the same gibberish. PGP then uses my Private-key to encrypt that hashed result and includes that ether as an attachment to the email or at the bottom of the body.

To verify the integrity of a email the receiving PGP aware application uses the Public-key to decrypt the attached signature and reads the included hash. At this point you have already verified the signature was created using the Private-key because if it had been altered in any way after encryption the Public-key would no longer work. The next step is for the receiving copy of PGP to run the email through the same hash as before, SHA256, and then compare the hash encrypted in the email with the hash it just created. If the two match the email has been verified and you can be sure it has not been altered in transit.

How about encrypted messages

The process for full message encryption is slightly different. The problem with Public-key cryptography is it is incredibly expensive in computational power and CPU time and far large messages it is impractical to encrypt the whole message using a Private-key, so instead we use Symmetric-key encryption. Unlike Public-key encryption Symmetric-key encryption uses the same key to encrypt and decrypt a message.

So now when I send an encrypted message PGP signs the message in the same way detailed above then generates a large random password then uses this to encrypt the message. Now we have an encrypted block of text and a key to decrypt it again and we have to get both to the recipient without the decryption key becoming public, so we call on Public-key cryptography again. Using the recipients Public-key we can no encrypt our generated Symmetric-key and include it in the email header. At the other end the recipient uses their Private-key to decrypt the start of the email then can use the Symmetric-key we provided them to decrypt the message. This actually allows you to send the same email to multiple recipients as well, all we have to do is use the public-key of each person to encrypt a copy of the Symmetric-key.

Why Isn’t It Used More

PGP key management is hard work. Generating key, managing them and adding support to email applications that do not already support them is not for the faint hearted and the process is quite geeky. So while support is there its not easy to use, in simple terms it doesn’t yet pass the granny test.

I hope this will change in future and by signing the majority of my messages and writing these posts I would like to think that I can make it a little easier to get involved. Cryptography and PGP technique in particular is a subject I am interested in. I have given several talks to The Software Society (my local LUG) on the topic and plan to give another over the summer in the hopes of increasing awareness to my little corner of the universe.

If you have any questions or struggle to implement PGP in your own corner please drop me a line and I will do the best I can to help. Even if, like me, you see no reason to encrypt your emails the advantages of being able to sign your emails is huge deal in a world of spam and viruses being distributed by email – often appearing to come from an address you know.

OpenPGP: How do I create a OpenPGP Key?
03 May

OpenPGP: How do I create a OpenPGP Key?

Creating a Secured Key

When you build a PGP key you going to start using that key to verify your identity, so like all other forms of identification you have to protect it. Unfortunately to make PGP usable you cant permanently store you private keys locked in a safe, you actually need a copy of it one your computer, phone, table, laptop, basically any place where you want to send verified emails or decrypt messages you receive.

So what do you do if you phone or laptop are stolen? Even if you have secured your private-key with a strong password it is still at risk from someone with direct access to it.

Protection Using Subkeys

There isn’t allot of information on web about how to secure your key in this situation. I was able to find a few reference sites most notably the Debian Wiki about Subkeys.

When you create a OpenPGP key you are creating one key for signing and another for encryption. Its the signing key that is your master key and the one you need to protect. So after creating a new OpenPGP key you can create a new subkey just for signing.

This way the only things stored on your mobile device are your encryption key and your signing-subkey. If you lose control of your laptop, but still retain control of you master key, you can revoke the sub signing and encryption keys and create replacements.

If an attacker were able to break your password they would get access to anything encrypted before you revoked the key but nothing after that point. They could also only sign emails and files using the subkey you just revoked and any receiving PGP application would see that the key used to sign the message had been revoked and not validate the signature.

So how do we do it?

Step-By-Step

Creating the Keypair

Use the gpg --gen-key command to create the new keypair

You will be prompted to enter a password, its a good idea to make this a secure one; hard to guess and one you want forget. Keep it safe. If you lose your password you could lose control over your key and will have to start again.

Preferred Hash

PGP uses hashes through the signing and encrypting process, I’ve better explained this on the “How is works” page. To strengthen your key you can set your preferred hashes. This is useful because as time moves on and computers become more powerful weaknesses are being discovered in previously thought secure hashes such as SHA-1.

Use the gpg --edit-key command and when prompted enter the commandsetpref SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed, then save.

Subkey for Signing

OpenPGP subkeys work the same as normal (master) keys, expect they are mathematical related to the master key and they can be used for signing or encrypting. What makes them special here is they can be revoked and store independently of the master key.

Again use the gpg --edit-key command and type addkey. Select a sign only key, ether 3 or 4 depending on if you want to use DSA or RSA. After the new key is ready type save.

Revocation Certificate

Since we are creating subkeys we do not have to worry about theft of a laptop or phone. In that case you could still use your master key to revoke only that subkey. What I describe bellow is when you lose your master key and must revoke everything.

If you ever lose your private key you will have no way of generating the revocation certificates needed to revoke your new key. So best practice is to generate those certificates now and store them in a safe place encase you need them later.

You can do this from the command line with the command:

However I has also worked on a bash script that can automate the process of creating these certificates. More information on this is available from the project page.

Export The Final Product

Now export your keypair. You can export both the private-key and public-key using these commands:

You should protect these two files. Do not keep them on your laptop of mobile. The private file we exported contains your master key. Losing this could compromise your entire keypair.

Creating your Laptop Key

Now that your master key is ready you can create your laptop key. GPG does not make this easy, but with a little trickery you can make it work. These instructions assume you have created your master key on your laptop, if you have created your key on your desktop machine you can just skip the step two and not delete your secret key.

  1. Start by exporting your subkeys gpg --export-secret-subkeys 1FA1E814 > 1FA1E814.sub.gpg
  2. Next delete the master key from your key ring gpg --delete-secret-key 1FA1E814
  3. Now reimport the subkeys back into your keyring, or if you are not working from your laptop just import the subkeys theregpg --import 1FA1E814.sub.gpg.

Using your new key

You can now use your laptop keypair to sign, decrypt or encrypt emails and files. If you want to sign someone else’s key or revoke a subkey attached to your mast key you need to use the original master key.

Now that your key is ready for public consumption your can start sharing it. You can distribute your key anyway you like, but the simplest solution is to send it to a key server:

There are hundreds of key servers online, but you don’t need to send your key to all of them. In most cases any key server you use will distribute your public key across all the others. This process is fully automatic but it can take a few days for your key to appear on them all.

OpenPGP: Encryption should be easier than this
02 May

OpenPGP: Encryption should be easier than this

Why I Digitally Sign My E-Mail

Most e-mails I send are digitally signed using a process called “Pretty Good Privacy”, commonly referred to as PGP or GnuPG. PGP has been around since 1991 yet still is not commonly supported by the majority of email clients, at least in the Microsoft echo system, or webmail applications like Gmail or Yahoo Mail. When a digitally signed email is displayed in applications that do not support PGP you may see one of two things; either there will be an attached PGP.sig file or the message may start with “BEGIN PGP SIGNATURE” and appended to the bottom of the text will be a block of gibberish text. These components are used by PGP aware applications to cryptographically verify the identity of the sender. If you also have or use PGP I could send you encrypted email so that only you can read it. Over the next few pages I will give some background on PGP and why I use it.

Email Attachments

Since implementing PGP in my in all my email clients I will no longer open attachments or click links in unsigned emails. Like all security mined people this rule will no doubt cause problems for some and will make the internet a less user-friendly place, but with the amount of spam and viruses delivered by email – often coming from addresses you know – there is no better protection available, likewise I will never send an attachment unsigned.

Background

In 1991 PGP was created by Phil Zimmermann as a way to digitally sign or encrypt messages and file. This is achieved using Public-key cryptography. When you create a PGP key you are creating two very large numbers that are mathematically related, but due to the size of these numbers it is not possible to derive one from the other. So you now have two keys, one considered private the other public and as the name suggests who must keep the Private-key secret from everyone but you can share the Public-key with the world.

I was planning to include a section on this page detailing how PGP works but as I started writing it quickly grew beyond the scope I had indented this introductory page to be. If you are interested in the propeller hat explanation of how PGP can encrypt and digitally verify messages you can find it on at the “How does it work” page.

My Keys

My public keys are published all over the net; on key servers, in my DNS records, on this site on my “OpenPGP Keys” page and on some mailing lists. That is the way you want your public keys after all.

OpenPGP: GPG Cheat Sheet
24 Mar

OpenPGP: GPG Cheat Sheet

You can’t have enough cheat sheets on the net. Well you probably can, but I still wanted to add my own to the mix. I use the GnuPG command line for almost everything, bar actually sending email so this is a nice little reminder to myself what I’m doing

Creating a new Key First steps

gpg --gen-key

Browsing your keyring What have you got
  • List all public keys gpg --list-public-keys
  • List all private keys gpg --list-secret-keys
  • List everyone who has signed a key gpg --list-sig (0xKEYID)
  • Get the full fingerprint gpg --fingerprint (0xKEYID)
Exporting
  • Export your public key to a file gpg --armor --export (0xKEYID)
  • Upload a key to the keyserver. Good for new keys, or after signing someone else’s
    • Using the default Key server gpg --send-keys (0xKEYID)
    • Specifying a Key server gpg --keyserver sks.research.nxfifteen.me.uk --send-keys (0xKEYID)
  • Export/Backup you private key `gpg –armor –export-secret-keys (0xKEYID)
Searching for a key
  • Finding someones key
    • Using the default Key server gpg --search-keys user@email.example.com
    • Specifying a Key server gpg --keyserver sks.research.nxfifteen.me.uk --search-keys user@email.example.com
Encrypting/Decrypting
  • Encrypt a file for someone, by their email gpg --encrypt filename.txt --recipient user@email.example.com
  • Encrypt a file for multiplie people, by their email addresses – It’s usually a good idea to encyrpt to your own key as well or you will not be able to decrypt the file latergpg --encrypt filename.txt --recipient user1@email.example.com --recipient user2@email.example.com
  • Encrypt a file for transmission over text – email, IRC, Jabber etc.gpg --armour --encrypt filename.txt --recipient user1@email.example.com --recipient user2@email.example.com
  • Decrypting a file gpg --output filename.txt --decrypt filename.txt.asc
Import keys You need to get them somewhere
  • Importing from a text file gpg --import publickey.asc
  • Restore a backup of a private key gpg --allow-secret-key-import --import privatekey.asc
Keys Maintenance Revoking
  • Creating a revocation certificate. You must has the private key to do this, if you have lost your private key, well thats when problems kick in gpg --output revoke.asc --gen-revoke 0xKEYID
  • To revoke a the key all you need do is import the revoke.asc into your keyring gpg --import revoke.asc
  • To make sure everyone knows your keys been revoked you need to publish the updated public keygpg --keyserver sks.research.nxfifteen.me.uk --send-keys (0xKEYID)
Keys Maintenance Key Signing
  • You need to edit the key gpg --edit-key 0xKEYID

From here ‘help’ will give you a list of your options, but to sign a key you can ether type ‘sign’ or ‘tsign’. The man pages give a better indication of what the difference is ‘man gpg’ but ‘sign’ is usually sufficent. After they key is signed type ‘save’ and ‘quit’ then you can ether send the key to a keyserver for download by its owner of export the public key and send it by other means, this usually means encrypted email.

Signing and Verifying files
  • To sign a file with your default key use this gpg --detach-sign --armour filename.txt
  • To verify a signed file but put the output from above filename.txt.asc gpg --verify filename.txt.asc
OpenPGP: Key Signing Policy
19 Feb

OpenPGP: Key Signing Policy

Since April 2012 I have held the position of Chairman of The Software Society Ltd. On the 23th of March this year, 2013, it was decided that the board of directors and office bares (Chairman, Company Secretary and Chief Financial Officer) should all create an use OpenPGP keys for all official business.

It was also decided that each office barers key should last as long as they are in office, the new incombant creating a new key apon their election.To this end, during my time in the post my key will be 0x6415679569aa4946 and will be subject to the same signing policy as I has been in use on my personal key. This is detailed bellow.

Preamble

This policy is valid for all signatures made by the following GnuPG keys:

The most recent version of these keys are available from the key server at sks.research.nxfifteen.me.uk or for download from My GPG Page

This policy was first written on 2011-06-22 but the polices listed here have been followed since the creation of the key four days earlier on the 18th. Content and structure of this document are strongly based on the OpenPGP Key Signing Policy of Marc Mutz (Link no longer available) and Jörgen Cederlöf (Link no longer available) but have been slightly modified from the original sources.

Location

I live in Dundee (Scotland) and am available to sign keys any time. If you want to arrange for a key-signing, your best chance of meeting me is in or near Dundee. Occasionally I’m in St.Andrews, Cupar and Perth. I can be reached thru the/feedback form on this site, Just be sure to include the phrase ‘key-signing’ in the subject line. I am also listed at biglumber.com, a webpage about key signing coordination. Meetings at computer related fairs are possible as well.

Usually I keep track of upcoming events where it would be possible. So if you would like to meet in order to sign keys check my events diary to find out where I will be.

Prerequisites for signing

The signee (the key owner who wishes to obtain a signature to his/her key from me, the signer) must make his/her OpenPGP key available on a publicly accessible keyserver (see above for example keyservers).

The signee must prove his/her identity to me by way of a valid identity card or a valid driving licence. These documents must feature a photographic picture of the signee. No other kind of documents will be accepted. This also implies that the signee’s key must feature his/her real name in order to be checked up on his/her identity card. A key which only contains a pseudonym will not be signed.

For people from outside the European Union I will check both of these two tokens (since I cannot assess their risk of fraud). Exceptions may be made if there is a good reason for me to do so.

The signee should have prepared a strip of paper with a printout of the output gpg --fingerprint 0x12345678 (or an equivalent command if the signee does not use GnuPG) where 0x12345678 is the key ID of the key which is to be signed.

A handwritten piece of paper featuring the fingerprint and all UIDs the signee wants me to sign will also be accepted.

The above must take place under reasonable circumstances (i.e. ourselves not being in a hurry, exchanging key data at a calm place and so on).

The act of signing

After having received sufficient proof of identity I will sign the signee’s piece of paper myself to avoid fraud, and eventually sign the signee’s key.

The signed keyblock will then be mailed to the signee, or uploaded to a keyserver if expressly wished.

Key signing is performed on the understanding that the act of signing is mutual. If the signee fails to sign my key in return I reserve the right to revoke my signature from their key.

Signing requests of transitions to new keys

I have been asked what my position is towards requests from people (whose keys I had already signed) to also sign their new keys.

In principle, I agree to the procedure when I am reasonably sure the request is not bogus/a scam, and the following conditions are met:

Any signing request of transition to a new key

  • must at least be signed by the still valid original key (which I also signed),
  • the new key must also be signed by the still valid original key (which I also signed),
  • the owner of the new key must cross-sign my keys in return with the new key first,
  • the new key will receive the same level of signature as the still valid original key (which I also signed).

However, such a signing request may be declined without giving reasons. If unsure, enquire first.

Levels of signatures

Level 0

A level of 0 is given to keys of Certification Authorities since in most cases the key owner is a whole organization and not a single person. Usually the fingerprints of those keys have to be verified by getting them from the corresponding website of the CA and cannot be checked by exchange with a member of the CA who is in charge. These signatures are the weakest in my web of trust.

Level 1

If I have had contact with someone through signed or encrypted e-mail over a time long enough to rule out at least temporary man-in-the-middle attacks, and I have verified the key with a key downloaded from his/her personal web page, or signed emails/fingerprints on public mailing lists, but I have not met the person or verified the key in any other way, I may sign the key with cert check level one.

Level 2

A level of 2 is given to sign-only keys. It is not clear to determine if the owner of the mail account is the same as the key owner because encryption cannot be used, hence the signatures only receive a lower level of 2.

Level 3

A level of 3 is given to sign-and-encrypt keys: I have met the signee in person, I have verified his identity card (passport, or driving licence) and his key’s fingerprint. I was also able to send my signatures encrypted with the corresponding key of the signee. These signatures are the strongest in my web of trust.

Photographic UIDs are also going to be signed with a level of 3 if I can still remember the signee’s face when I will be back at home.

I will also sign keys at level 3 when I know the signee personally, I do not require ID card or the above formal procedure. A meeting where we exchange fingerprings is enough. Naturally, it would be extremely hard to trick me into signing a false key this way.

Here are some links which you may find useful or interesting: Key signing policies of other people:

Change Log

  • Version 1.0.5.0, 2014-12-14 – Content migrated to new markdown site
  • Version 1.0.4.0, 2013-09-21 – Applied this policy to my smartcard key
  • Version 1.0.3.0, 2013-03-25 – Applied this policy to my second key
  • Version 1.0.2.0, 2013-03-22 – Removed dead URL from links
  • Version 1.0.1.0, 2012-01-19 – Content Recovered from Google Cache
  • Version 1.0.0.0, 2011-11-30 – Initial Release.