There are two types of security in the Wi-Fi protocol: WPA2 Personal and WPA2 Enterprise. WPA2 Personal (a.k.a. WPA2 Passphrase) is designed for small personal networks, and requires that each device have a common passphrase used to allow association with the network. WPA2 Enterprise is based on the 802.1X standard, where each client device has a unique set of pre-established credentials, and the access point connects the client device to an external database to verify those credentials before allowing association with the network.
Neither of these security methods are appropriate for the small/medium business market (SMB). WPA2 Personal does not offer the level of security needed by SMBs, but WPA2 Enterprise is quite complicated to operate in practice, and generally requires dedicated IT staff to implement and maintain the databases and the credentials for client devices.
Accordingly, a security solution is needed for the SMB where individual client devices can be managed, but without the complexity of a full WPA2 Enterprise solution. A few AP vendors, including Aerohive, Ruckus, and Xirrus, implement variations on Private Pre-Shared Key, which combines the use of a passphrase with an internal database to provide each client device a unique WPA2 passphrase. If implemented correctly, this approach can provides enhanced security while being fairly simple and straightforward to implement.
The Problems with WPA2 Personal
WPA2 Personal relies upon a pre-shared-key, or passphrase, to authenticate to the Wi-Fi network. All devices use the same WPA2 passphrase to connect to the network. This is suitable for home and very small network environments implementing a handful of devices that are all under the control of a single set of owners.
WPA2 Personal is commonly used in the SMB environment, but it is becoming increasingly problematic because of several security risks.
- Distribution: The WPA2 passphrase is usually given out to employees, so that they can configure their own personal devices to connect to the Wi-Fi. If the WPA2 passphrase is shared, then any employee could consciously share the WPA2 passphrase with a third party. Even if the SMB has an IT person do this configuration and not publicize the WPA2 passphrase, the WPA2 passphrase is present on the device of any former employees after they leave the employ on the SMB. While the SMB could change the WPA2 passphrase on their Wi-Fi and all connected devices, this is logistically challenging and therefore isn’t generally done.
- Automated Tools for Sharing Networks on Social Media: There are now automated tools that automatically facilitate the sharing of WPA2 passphrases over social media, including Wi-Fi Sense in Windows 10 and Wi-Fi Master Key on Android. These applications are intended to share someone’s personal network with their friends, but the ability to control who this access is shared with is quite limited. Accordingly, users may unknowingly share the WPA2 passphrase over social media. While the WPA2 passphrase is not directly shared with the third party user, it is provided to the device and allows third party devices on to the Wi-Fi network, which effectively breaks the security of the network. For more information, check out http://www.emperorwifi.com/2015/11/wi-fi-master-key-brings-windows-wi-fi.html and http://www.emperorwifi.com/2015/06/wi-fi-sense-how-microsoft-has.html)
- WPA2 Personal Can Be Hacked: When a WPA2 Personal or Enterprise connection is established, a private set of encryption keys is established between the access point and each associated client device. For WPA2 Enterprise, the seed for this encryption key is unique and comes from the authentication server. For WPA2 Personal, the seed for the encryption key is the WPA2 Passphrase. A hacker who already possesses the WPA2 passphrase and can capture the association traffic of a client device can derive the encryption key for that client device and thus decrypt wireless traffic from that client.
- Ineffective for Guest Networks: Many SMBs open up their own networks (or more hopefully set up a dedicated SSID and VLAN) for visitors or customers. This is especially important in service businesses, such as restaurants, cafés, hotels, doctor’s offices, or any other locations where customers need to wait for long periods for a service to be provided. Many SMBs protect this network with WPA2 Personal, which is quite ineffective as this WPA2 passphrase must be distributed publicly, making it an ineffective security measure. See http://www.emperorwifi.com/2015/05/how-operators-can-make-hotspots-and.html for more information on how to more properly secure a guest network.
The Problems with WPA2 Enterprise
In WPA2 Enterprise, the client device connecting to the Wi-Fi network gets authenticated to an authentication server (i.e. a database server via RADIUS) before association to the access point is completed. The authentication server can either be internal to the access point technology (i.e. implemented on a controller), or it can be an external server on the local network or even the Internet. The authentication process is known as Extensible Authentication Protocol (EAP), and there are several variations of EAP that dictate different types of credentials and encryption required by both the supplicant (i.e. client device) and the authentication server (i.e. external database accessed via RADIUS). Most modern EAP implementations require mutual authentication between the supplicant and authentication server, which typically requires a signed certificate on the database server and either client certificates, tokens, or other credentials on the client device. The most difficult part of implementing EAP are supporting the client devices, as each client device must have appropriate credentials pre-loaded. Additionally, many IoT devices and network appliances simply do not have the capability of supporting WPA2 Enterprise.
The authenticator (i.e. the access point) acts only as a middleman during the EAP authentication process, and thus doesn't care which EAP method gets used. Configuring WPA2 Enterprise on an AP is therefore quite simple, as all the AP needs to know is the IP address and port of the RADIUS server, along with a shared secret (i.e. password) for authenticating communication between the AP and the authentication server over the wired network.
When a client is approved for access to the network by the authentication server, the server passes information to the AP, including the fact that the client device is approved and the seed for generating the unique unicast AES encryption key between the AP and the client device.
It is possible to set up the authentication server to pass additional information to the AP when a client successfully authenticates. One application of this is dynamic VLANs, where the authentication server tells the access point the desired VLAN tag of the client device is passed to the AP. The AP is then responsible for tagging the traffic from the client device for the VLAN identified by the external authentication server. Using this approach, multiple client devices can associate to a single VLAN on a single access point, but each be on a different VLAN, based on the information received from the authentication server.
Private Pre-Shared Key
PPSK integrates WPA2 Personal and WPA2 Enterprise in a way that is quite suitable for the SMB market. With PPSK, each user / client device is assigned a unique WPA2 passphrase, which is tracked by the access points in a database to match up a passphrase with the client device MAC address(es). From the client device’s perspective, this is still WPA2 Personal, so there are no client / server certificates to manage nor are there issues with compatibility to IoT and other Wi-Fi appliances. Since the WPA2 passphrase is unique to each user / client device, the risks with WPA2 Personal are eliminated. The WPA2 passphrase for an individual employee can simply be disabled or changed. Since it is not publicly known, it also cannot be hacked by a local wireless packet sniffer. Additionally, add-on features to WPA2 Enterprise like dynamic VLANs can also be enabled for PPSK very readily.
While the current implementations are proprietary, it actually is fairly straightforward to add this feature to any access point platform with centralized management. The following is required to implement PPSK on an AP platform:
- A central database of users, device MAC address(es), and passphrases. A copy of this should ideally reside on-site on a controller, but if no on-site controller is in place, then the database can be located on a cloud-based controller (a cloud-based database may lead to association and roaming delays). This can be the same RADIUS database that supports WPA2 Enterprise, The MAC address(es) can either be entered up-front by the network administrator, or with only one MAC address per passphrase, can be added to the database upon first use of the passphrase to minimize overhead burden.
- 802.11r support for fast roaming. This is especially important for a cloud-based database.
- AP firmware needs to be able to select the option “WPA2 PPSK” for the security of an SSID and verify passphrase against APs central database.
- A user interface in the on-site or cloud controller to allow network administrator to input the following parameters:
- Name of user
- Passphrase (a random character generator would be a good feature here)
- MAC address(es) of allowed devices
- Dynamic VLAN ID (if supported)