Connect Raspberry Pi to a WiFi Enterprise with WPA supplicant

It’s not a surprise that, at NetBeez, we love the Raspberry Pi! This little device can do magic on wired as well as wireless networks. Few weeks ago, Panos posted an article that offered some examples on how to use the Raspberry Pi for distributed monitoring with Iperf. Here, I want to talk a little about using this platform, or any other Linux client, to connect to enterprise wireless networks.

Wireless security

First of all, there are different types of security settings that can be used for wireless networks. In the section below, I want to list each of one them, from the weakest to the most secure option and shed some light on all options available.

Open

This configuration does not require any password. The wireless client simply connects to the open SSID. This is the case of a coffee shop, like Starbucks, or of an enterprise’s guest internet access that offers free wireless services to its customers. Typically, a client that accesses such a free wireless service is redirected to a captive portal where it has to accept the terms and conditions of service before being able to use the network.

WEP

WEP (Wired Equivalent Privacy) is a security setting that uses pre-defined passwords. It can be easily exploited and, for this reason, should not be used to protect your home or work wireless network.The most common versions of WEP are:

WEP-40 also known as WEP-64: It uses 40 bits of key and a 24-bit initialization vector. It can be also expressed with a string of 10 hexadecimal characters (remember 4 bits for 1 hex).

WEP-104 also known as WEP-128: It uses 104 bits of key and a 24-bit initialization vector. It can be also expressed with a string of 26 hexadecimal characters.

WPA

WPA (Wi-Fi Protected Access) is, from a security perspective, more secure than WEP, but it can be still exploited by an attacker. For the key encryption protocol, WPA can be configured to use TKIP or CCMP, which is based on AES (CCMP and AES are used interchangeably). CCMP is more secure than TKIP and should be used when possible. However, not all the hardware vendors may support CCMP. For this reason, WPA networks can be configured with the following options:

WEP CCMP

WEP CCMP/TKIP (CCMP preferred, TKIP as fallback)

WEP TKIP

For the authentication part, in WPA can either use:

A Pre-Shared Key (WPA-PSK) that is convenient for a home or small office environment. In this setup, all the users share the same password so if this is compromised or one of the employees leave, you will have to change the password and update your access point and wireless clients.

The Extensible Authentication Protocol (EAP), a framework that support different authentication methods. This is a form of enterprise authentication that creates a unique authentication profile for each user. The EAP framework will be discussed in the next paragraph.

WPA2

Also known as IEEE 802.11i-2004, WPA2 only uses CCMP as the encryption algorithm. As with WPA, the authentication on WPA2 networks can be based on pre-shared keys (WPA2-PSK) or on the EAP framework.

WPA supplicant

The WPA supplicant software (available here) is not mandatory if you are connecting your wireless client to a home network that uses one of the pre-shared key methods (WEP, WPA-PSK, WPA2-PSK) to authenticate its clients. Since in our case we want to deploy our wireless client in an enterprise network, the WPA supplicant software it is needed. Wireless enterprise networks generally use one of the most common WPA or WPA2 Extensible Authentication Protocol (EAP) methods, such as PEAP, EAP-TLS, EAP-TTLS, and LEAP.

To instruct our wireless Raspberry Pi to use the WPA supplicant software, we have to edit the /etc/network/interfaces and add the following configuration lines under the wlan0 interface:

Then we have to edit the /etc/wpa_supplicant/wpa_supplicant.conf file based on your specific configuration:

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

ctrl_interface=/var/run/wpa_supplicant

update_config=1

network={

ssid=""

proto=””

pairwise=””

group=””

key_mgmt=””

eap=””

identity=""

password=""

ca_cert=""

client_cert=””

private_key=””

private_key_password=””

phase1=””

phase2=""

eapol_flags=””

}

In the following table I listed some of the most important configuration options to consider when editing the wpa_supplicant file:

Option

Defines

Values

proto

Wireless security settings

Default value: WPA RSN

WPA = for WPA only networks

RSN = for WPA2 only networks

Leave default value for WPA/WPA2 networks.

key_mgmt

Accepted authentication protocols

Default value: WPA-PSK WPA-EAP

WPA-PSK = for WPA with pre-shared key

WPA-EAP = for WPA using EAP methods

IEEE8021X = IEEE 802.1X using EAP

NONE = plaintext or static WEP

pairwise

Accepted pairwise (unicast) ciphers for WPA

Default value: CCMP TKIP

CCMP = for WPA2 only networks

TKIP = for WPA only networks

Leave default value for WPA CCMP/TKIP networks

group

Accepted pairwise (broadcast/multicast) ciphers for WPA

Default value: CCMP TKIP WEP40 WEP140

CCMP = for WPA CCMP or WPA2

TKIP = for WPA TKIP

WEP104 = for WEP with 128 bits key

WEP40 = for WEP with 64 bits key

auth_alg

Accepted authentication algorithms

If not set, automatic detection is used

OPEN = required for WPA and WPA2

SHARED = required for WEP

LEAP = required for LEAP only

psk

Pre-shared key

Specify the 256 bit pre-shared key, for WPA-PSK and WPA2-PSK networks

eap

EAP methods

Define the list of EAP methods accepted. If not set, all the methods are accepted by default. Otherwise, the user can restrict accepted methods, which should be space separated:

PEAP = required for PEAPv0/EAP-MSCHAPV2

TLS = required for the EAP-TLS with client and server certificate

TTLS = required for EAP-TTLS

LEAP = required for LEAP

EAP methods

In wireless enterprise environments, the EAP framework is king. Below are the most common EAP methods along with their wpa_supplicant settings (taken from here):

PEAP (Protected EAP)

There are many variations of the Protected EAP method, but the PEAPv0/EAP-MSCHAPV2 is generally the most common configuration that is used in an enterprise environment. This authentication protocol requires the server-side public key certificate to establish the secure TLS tunnel (PEAPv0) that protects the transmission of the user credentials (MS-CHAPV2).

1

2

3

4

5

6

7

8

9

network={

…

key_mgmt=WPA-EAP

eap=PEAP

identity="<em>user@example.com</em>"

password="<em>password</em>"

ca_cert="/etc/cert/ca.pem"

phase2="auth=MSCHAPV2"

}

EAP-TLS (Transport Security Layer)

This method is considered one of the most secure and relies on a RADIUS server as the authentication backend. It uses the Public Key Infrastructure (PKI) and requires an x.509 client side certificate to communicate with the authentication server. It is covered in the RFC 5216. The client certificate, client private key, and CA certificate should be stored in PEM/DER format. If you receive your certificate in PKCS#12 format, you can convert it to the PEM format with the following commands:

# Extract the user certificate and private key from the P12 container

1

openssl pkcs12-inexample.p12-out user.pem–clcerts

# Extract the CA certificate from the P12 container

1

openssl pkcs12-inexample.p12-out ca.pem-cacerts-nokeys

The wpa_supplicant.conf file will be configured the following way:

1

2

3

4

5

6

7

8

9

10

network={

…

key_mgmt=WPA-EAP

eap=TLS

identity="<em>user@example.com</em>"

ca_cert="/etc/cert/ca.pem"

client_cert=”/etc/cert/user.pem”

private_key=”/etc/cert/user.key”

private_key_password=”<em>password</em>”

}

EAP-TTLS (Tunneled Transport Layer Security)

This method is very similar to the PEAPv0/MSCHAPV2 method. A server-side public key certificate is used to authenticate the server and establish a secure tunnel through which the client credentials are transmitted. The client can be authenticated via a CA-signed certificate with the server or just authenticates via traditional username and password credentials.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

network={

…

key_mgmt=WPA-EAP

eap=TTLS

# Phase1 / outer authentication

anonymous_identity="anonymous@example.com"

ca_cert="/etc/cert/ca.pem"

# Phase 2 / inner authentication via user certificate

phase2="autheap=TLS"

ca_cert2="/etc/cert/ca2.pem"

client_cert2="/etc/cer/user.pem"

private_key2="/etc/cer/user.prv"

private_key2_passwd="<em>password</em>"

priority=2

}

LEAP (Lightweight Extensible Authentication Protocol)

This method was developed by Cisco before the ratification of the 802.11i standard and is supported by a wide range of operating systems (Windows, Linux, Mac) and wireless vendors. LEAP supports Windows NT/2000 Active Directory profiles and authenticates against a RADIUS server. For this reason, LEAP was largely adopted in wireless enterprise environments and may still be used by several organizations. However, since it relies on the MS-CHAPv2 authentication protocol, it can be exploited, so it is highly recommended to use it with complex passwords or to adopt, if possible, a different EAP method.

1

2

3

4

5

6

7

8

network={

…

key_mgmt=WPA-EAP

auth_alg=LEAP

eap=LEAP

identity="<em>user</em>"

password="<em>password</em>"

}

I hope that this post was beneficial to shed some light on how you can configure your wireless Raspberry Pi, or Linux client running a WPA supplicant, to connect to a wireless enterprise environment. If you want to learn more about NetBeez and WiFi monitoring with Raspberry Pi, download this guide.