Keys, Keys, and Even More Keys!



I thought I had a good understanding of how the WPA/WPA2 encryption key generation process worked, that was, until I read Chapter 5 of the CWSP (Certified Wireless Security Professional) Study Guide. I was definitely amazed and a little confused of what all happens in the background when a client authenticates and the encryption keys are created. Dealing mostly with personal or small office wireless environments I took a special interest in the process to generate the encryption keys in small office home office (SOHO) networks. I’m a firm believer that a strong passphrase is mandatory when using WPA/WPA2 Personal, and part of writing this blog was not only my way to fully understand the encryption key creation process, but at the same time to stress how important it is to select a completely random WPA/WPA2 passphrase. An easily guessed passphrase or a common dictionary word can expose your wireless network and connected devices to hacking or decryption of the data. The passphrase will not only authenticate clients to the access point, but it is also the initial seeding material to create the master keys that are then used to create the transient and temporal keys that encrypt the unicast data frames and broadcast and multicast frames.


Let’s start by defining the alphabet soup of letters and give some quick definitions to the important terms being used in the article.

WPA/WPA2 Passphrase: Selected by the network owner and entered as a simple ASCII character string from 8 to 63 characters. The passphrase is configured on the access point and manually entered on the client devices that will join the APs wireless network.

Authenticator: In a SOHO network this will be the access point.

Supplicant: Any device wanting to join an access points service set.

Pre-Shared key (PSK): The result when the passphrase goes through the passphrase to PSK mapping formula.

PMK (Pairwise Master Key): Is the highest order key and derived from the pre-shared key (PSK).

GMK (Group Master Key): Generated by the authenticator (access point) and is the seeding material for the group temporal key.

4-Way Handshake: Uses the pseudo-random function to create and distribute the dynamic encryption keys.

Nonce: A randomly generated value only used once.

PTK (Pairwise Transient Key): Final encryption key used to encrypt unicast data traffic.

GTK (Group Temporal Key): Final encryption key used to encrypt broadcast and multicast traffic.

Selecting the Passphrase

The first step is to choose the passphrase and enter it in the security section of the wireless routers management interface. Notice I did not say select a password! As mentioned before avoid using common dictionary words, and don’t use your name, address, phone number, pet’s names, favorite sports team name, etc… It is recommended to select a completely random passphrase and using a passphrase generator is the best option to select a random passphrase. For help on selecting a highly secure passphrase read my earlier blog post on creating a secure WPA/WPA2 passphrase.

WPA/WPA2 passphrases are static and susceptible to offline dictionary attacks, and it will become very clear why this passphrase be absolutely random for maximum security of the wireless network.

The graphic below shows the encryption key generation process and can be referenced throughout the article.

WPA/WPA2 Encryption Key Generation

WPA/WPA2 Encryption Key Generation

Passphrase to PSK Mapping

Manually enter the passphrase on the client devices that will be joining the wireless network. The passphrase authenticates the device to the APs wireless network, and behind the scenes the passphrase will go through the “passphrase to PSK mapping” function to transform it into the 256-bit Pre-Shared Key (PSK).

Here is the formula to convert a passphrase to the PSK.

The whole point of the passphrase to PSK mapping formula is to simplify configuration for the average home network user. Anyone can remember an 8 to 63 character passphrase compared to a 256-bit PSK.

Master Keys

The PSK will become the Pairwise Master Key (PMK), so basically the PSK is equal to the PMK.

The authenticator (access point) generates the Group Master Key (GMK). The GMK is derived by the authenticator and used to create the Group Temporal Key (GTK). The GTK will be used by the AP and all the authenticated clients to encrypt multicast and broadcast traffic.

4-Way Handshake

The graphic below is from Chapter 5 of the CWSP Study Guide to further explain the 4-way handshake process.


The 4-way handshake is a 4 frame exchange (not including acknowledgements) between the supplicant and the authenticator. Using a pseudo-random function (PRF) the 4-way handshake will create the Pairwise Transient Key (PTK) by combining the PMK, an authenticator nonce, a supplicant nonce, the authenticator’s MAC address (AA), and the supplicant’s MAC address (SPA).

Here is the pseudo-random function formula and below the formula is a brief description for the 4 frames exchanged during the 4-way handshake.

Message 1: The authenticator sends its ANonce to the supplicant. The supplicant now has all the information needed to generate the PTK using the pseudo-random function. The PTK protects the unicast data traffic.

Message 2: The supplicant will send its SNonce to the authenticator. The authenticator now has all the information needed to generate a matching PTK using the pseudo-random function.

Message 3: The authenticator generates the GTK from the GMK and transfers the GTK to the supplicant. The GTK is encrypted using the PTK and a secure exchange takes place. The GTK protects the broadcast and multicast traffic.

Message 4: An acknowledgement that the client has successfully installed the PTK and GTK.

The client is now authenticated and possesses the dynamic encryption keys and can securely send and receive traffic through the access point.


In a SOHO network the passphrase is not only used for keeping unwanted devices from joining the network, but also the seeding material to create the transient and temporal encryption keys. If an attacker obtains the passphrase they could not only join the wireless network, but they could crack the PTK encryption key. If an attacker captures a 4-way handshake exchange between a client and the access point, and with possession of the passphrase the attacker has all the variables needed to duplicate the PTK. With the PTK the attacker can decrypt any unicast encrypted data frames between the individual client and the AP. Passphrase secrecy and having a passphrase that is not susceptible to dictionary cracking methods is vital for the security of any network using WPA/WPA2 Personal.

Extra Security Note: Having one person control the passphrase is probably a harder thing to do in a home network, but in a small office environment ideally one person should know the passphrase and enter it on the devices needing to connect to the wireless network. The less people who know the passphrase the more secure the network will be!

515 total views, no views today

» How to Secure SSH with Google Authenticator’s Two-Factor Authentication


How to Secure SSH with Google Authenticator’s Two-Factor Authentication
Published on August 14th, 2012  |  Written by: Chris Hoffman

Want to secure your SSH server with easy-to-use two-factor authentication? Google provides the necessary software to integrate Google Authenticator’s time-based one-time password (TOTP) system with your SSH server. You’ll have to enter the code from your phone when you connect.

Google Authenticator doesn’t “phone home” to Google — all the work happens on your SSH server and your phone. In fact, Google Authenticator is completely open-source, so you can even examine its source code yourself.

Install Google Authenticator
To implement multifactor authentication with Google Authenticator, we’ll need the open-source Google Authenticator PAM module. PAM stands for “pluggable authentication module” – it’s a way to easily plug different forms of authentication into a Linux system.

Ubuntu’s software repositories contain an easy-to-install package for the Google Authenticator PAM module. If your Linux distribution doesn’t contain a package for this, you’ll have to download it from the Google Authenticator downloads page on Google Code and compile it yourself.

To install the package on Ubuntu, run the following command:

sudo apt-get install libpam-google-authenticator

(This will only install the PAM module on our system – we’ll have to activate it for SSH logins manually.)

Create an Authentication Key
Log in as the user you’ll be logging in with remotely and run the google-authenticator command to create a secret key for that user.

Allow the command to update your Google Authenticator file by typing y. You’ll then be prompted with several questions that will allow you to restrict uses of the same temporary security token, increase the time window that tokens can be used for, and limit allowed acces attempts to hinder brute-force cracking attempts. These choices all trade some security for some ease-of-use.

Google Authenticator will present you with a secret key and several “emergency scratch codes.” Write down the emergency scratch codes somewhere safe – they can only be used one time each, and they’re intended for use if you lose your phone.

Enter the secret key in the Google Authenticator app on your phone (official apps are available for Android, iOS, and Blackberry). You can also use the scan barcode feature – go to the URL located near the top of the command’s output and you can scan a QR code with your phone’s camera.

You’ll now have a constantly changing verification code on your phone.

If you want to log in remotely as multiple users, run this command for each user. Each user will have their own secret key and their own codes.

Activate Google Authenticator
Next you’ll have to require Google Authenticator for SSH logins. To do so, open the /etc/pam.d/sshd file on your system (for example, with the sudo nano /etc/pam.d/sshd command) and add the following line to the file:

auth required

Next, open the /etc/ssh/sshd_config file, locate the ChallengeResponseAuthentication line, and change it to read as follows:

ChallengeResponseAuthentication yes

(If the ChallengeResponseAuthentication line doesn’t already exist, add the above line to the file.)

Finally, restart the SSH server so your changes will take effect:

sudo service ssh restart

You’ll be prompted for both your password and Google Authenticator code whenever you attempt to log in via SSH.

15 Responses

August 14, 2012 at 8:00 am
Excellent article. I use this authenticator for my main GMail account for a while now, and I really like the fact that I can have multiple secret keys and number generators on my phone. The trick is now to see whether I can replicate the secret key across multiple servers to have a single generated code to access multiple servers.

August 14, 2012 at 8:38 am
I’m in love with Google’s 2-factor auth. I use it for Google account(obviously), LastPass, SSH, and once implemented…dropbox =D

August 14, 2012 at 11:07 am
Tried this under my ubuntu 10.10 server. Even when adding a repo manually that I found it still could not find the libpam-google-authenticator package. Maybe it just doesn’t work for 10.10?

August 14, 2012 at 12:53 pm
Someone needs to add this to Tomato/DD-WRT

August 14, 2012 at 3:42 pm
I had this on my SSH server for a little while… it worked really well… and then I went to connect with WinSCP… there isn’t a great implementation for connecting via SFTP.

August 14, 2012 at 6:32 pm
I’m with Tim, I can’t really use this without WinSCP support…. sigh

August 14, 2012 at 11:01 pm
It seems that you’re using a libvte based terminal (gnome-terminal) in your example screenshots, since you are concerned enough about security to implement two factor auth, you really should check out this document, which documents a major security flaw in that library:

August 16, 2012 at 3:19 am
Interesting article, the idea looks interesting.

Just a quick question, can you still have several way to connect to your ssh server at the same time?

Basically, I’m usually connecting to my ssh server from my laptop or tablet, so I created a public/private pair of key (DSA), because it’s faster, more secure etc…

I would like to use the google system but only if I’m not able to use my private key. Is there is a a way to do that?

August 16, 2012 at 2:16 pm
For those that are concerned about your smart phone not have battery charge on being in an area that has no coverage, there is a simpler alternative at:

It uses simple USB flash drives and provides Two-Factor Authentication for:
1. OpenVPN
2. SSH
3. Web Single Sign On

August 16, 2012 at 6:01 pm
To both Tim and cpradio, not sure what you’re on about here. I’ve had Google Authenticator set-up for some time now on my SSH server, WinSCP seems to work fine for me. Just make sure you’re running the latest version. Failing that, if you use SSH keys, two factor authentication is bypassed. WinSCP supports both Challenge Response and SSH keys.

August 17, 2012 at 12:21 am
A million thank-yous!

August 17, 2012 at 3:07 pm
I think that the yubikey or softyubikey for gnome, kde, cinnamon and mate is a better solution. Please check them out. I solves all previous problems. Cheers!

August 22, 2012 at 9:02 am
@Toto: if you don’t have your private key on a device you are trying to login from, and you have setup the two-factor authentication with google authenticator, sshd will do two factor authentication. You don’t have to do anything, it will work exactly like you want. I have the same need and it works correctly i.e. uses key based login where private keys are available and two factor when keys are not available.

August 23, 2012 at 5:41 am
@aselvan : Thanks for your input, I actually tried that and it worked like a charm.

For those of you who are interested to do so, I recommend you to set the shared key as preferred login method.

September 13, 2012 at 12:30 am

I have two types of authentication on my server.
One is used just for my account to administer the server (not root) that has public/private keys
The second has just user and pass, but has shell access restricted, are locked in to using a shared ftp folder and are restricted from doing pretty much anything but ftp and http forwarding. (via a group policy in sshd)

I can see that above toto had asked if it was possible to use either public keys or authenticator if not available. is it possible to have the authenticator AND the pub/private key for the standard account, while leaving the accounts in my restricted group untouched.

its probably overkill, with what feels like 3 step protection, but i am curious if it is possible.

1,815 total views, no views today