Private Pre-Shared Key (PPSK) for Small Business

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:

1. Name of user
2. Passphrase (a random character generator would be a good feature here)
3. MAC address(es) of allowed devices 
4. Dynamic VLAN ID (if supported)

Dynamic VLANs: A simple explanation

Dynamic VLANs are a fairly common feature used in large corporate enterprise applications such as hospitals, universities, large corporate offices, and similar.  Dynamic VLANs are fairly unusual in SMB environments, as WPA2 Enterprise is required as a prerequisite, though using WPA2 Enterprise does not necessarily require use of Dynamic VLANs.   Thus, only some access point and switch vendors offer support for Dynamic VLANs. Nonetheless, it is a good option in some circumstances, and is another tool in the toolbox for Wi-Fi and network engineers 

VLAN Description and Background

While VLANs are defined by the IEEE standard 802.1q, there is no IEEE standard for dynamic VLANs.  It is one of those feature enhancements that one AP vendor (probably Cisco, but I don't know for sure) invented several years ago and many other AP vendors copied.

VLANs, or Virtual Local Area Networks, are a method of segmenting users into different groups that are normally isolated from each other.   It allows one physical set of network infrastructure hardware (i.e. router, switches, APs, cabling) to act like they are multiple parallel co-located networks, hence the term "virtual".  In addition to only requiring one physical set of hardware, VLANs are transparent to client devices.  Traffic is "tagged" as it enters the network either wired or wirelessly, traverses the wired network infrastructure with this identifying tag, and then the traffic is "untagged" when it leaves the network, either to another client device on the network or to the WAN / internet. I've given a detailed explanation of VLANs in a prior blog post.

Here is a simple analogy to visualize how VLANs work:  You send a letter in the mail and hand it to a postman, who takes this letter and puts it into a larger colored envelope to send it through the mail system.  The post office routes the envelope through their extensive network infrastructure based on the color, as different colors get handled and routed differently.  The postman on the other end removes the original letter from the colored envelope before delivering it to the intended recipient.

Virtually every enterprise AP vendor implements "static VLANs".  With static VLANs, each SSID is associated with one particular VLAN.  If you connect to the SSID "staff", all of your traffic is tagged to be on the staff VLAN.  Another device next to you connects to the SSID "visitor" on the same AP and is tagged to be on the visitor VLAN, and so forth.  The traffic to/from these devices behave as if they are on completely independent networks, even though they are actually on the same physical network.  Since most enterprise APs can typically support up to 8 SSIDs (per band), up to 8 different groups of users (i.e. VLANs) can be supported wirelessly.

Dynamic VLANs

In contrast, Dynamic VLANs assign users to VLANs based on their WPA2 Enterprise user credentials.  In WPA2 Enterprise, the client device connecting to the Wi-Fi network must be authenticated to an external server via RADIUS before association to the access point is completed.  This 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).  The authenticator (i.e. the access point) acts only as a middleman during the EAP process, and thus doesn't care which EAP process 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.  For Dynamic VLANs, 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 AP, but each be on a different VLAN, based on the information received from the authentication server.  Any arbitrary number of VLANs could be supported on a single SSID (up to 4096, since VLANs are defined by 802.1q as a 12 bit number in the MAC header frame - in practice an AP will runs out of client device capacity long before that).  If a client device is authenticated by the authentication server but for some reason the server does not identify a VLAN for the client device, the AP will use a particular hard-coded default VLAN (i.e. it behaves like a static VLAN).

It must be noted that the switch ports connecting to the APs, along with the backhaul ports interconnecting switches together and linking to the router, must all be configured to allow tagged traffic all of the VLANs that can possibly be assigned to client devices by the authentication server.

The particular VLAN tags themselves must be identified by the IT Administrator of the network for each device / user account in advance, and be part of the the user's database entry in the authentication server when their account is created.

Since dynamic VLANs require a lot of administrative overhead by the network operator,  it is generally only used on very large corporate networks where the IT department issues the client devices to users, or has an established process to register BYOD clients. 

Wi-Fi Master Key brings Windows Wi-Fi Sense to Android Devices. Welcome to the death of WPA2 Personal.

WPA2 Personal is dead.  If you want "protection" while you access the net,  you should just do it the old fashioned way... (just kidding)

 

Copyright 2015 Imperial Network Solutions, LLC

 

I’ve blogged in the past on Wi-Fi Sense in Windows 10  http://www.emperorwifi.com/2015/06/wi-fi-sense-how-microsoft-has.html.  Now, you can get the same functionality on Google Android devices with a Chinese app called Wi-Fi Master Key:  http://www.enterprisetimes.co.uk/2015/10/29/who-needs-wifi-passwords/

Wi-Fi Master Key works ostensibly the same way as Wi-Fi Sense.   With both systems, the SSID and passphrase are stored centrally and then the passphrase is shared directly with your device.  The focus by these services is on security for the user, not security for the network.  Both systems claim security because the user never sees the WPA2 passphrase.  This is little comfort to network administrators, because these users get authenticated to the network whether they explicitly know the passphrase or not.   The user is also “isolated” from the network.  In Wi-Fi Sense. this is really only one-way:  the connected network is considered “public” in Windows, and firewall rules are set up to not allow anyone else from the network to access the PC.  However, the connected PC can still access anything and everything else on the network.  Wi-Fi Master Key claims similar isolation functionality, which appears to use a similar firewall mechanism because the app only can control its own device device, not the network. 

In Wi-Fi Sense, the default settings are to share the network with all of your Facebook and Skype friends, though you have to explicitly agree via popup.  With Wi-Fi Master Key, it appears that sharing also needs to be done explicitly, though it is probably fairly easy to do so.  There are not even lip service given to controlling who the information is shared with – apparently once a network is available in Wi-Fi Master Key, it is available to anyone else running the app.    Once the network is shared, it is shared and difficult to

remove again.

Such apps are touted for the following types of networks:

• Public Hotspots:  Such networks are usually open (i.e. no encryption key) or have a WPA2 Passphrase that is publicly available and thus not a secret (see my blog on this subject: http://www.emperorwifi.com/2015/05/how-operators-can-make-hotspots-and.html)
  
• Private Homes:  Wi-Fi Sense is really touted for someone visiting the home of a friend or family member but too lazy to ask for the Wi-Fi passphrase.  These days, most consumer Wi-Fi routers come with a “guest network” feature so you can establish a secondary SSID for visitors that is isolated from your main network, though this assumes the consumer will be able to figure out and properly implement this feature, and not leave there device broadcasting “linksys” on Channel 6.

Large enterprises generally implement WPA2 Enterprise, which uses a back-end database implementing RADIUS to control what devices are on the network, and each user and/or device has its own unique set of credentials (either installed certificates or username/password information).  Large enterprises also tend to have mobile device management (MDM) systems to either control what devices are on the network, or at least control what applications are allowed with particular settings or banned.   As a result, large corporate and government networks are immune from these types of Wi-Fi password sharing applications.   

The challenge with WPA2 Enterprise, however, is that it takes a lot of IT resources to setup and maintain the database.  While large corporations have the knowledge, resources, and funds to do this, most small/medium businesses (SMBs) do not.   SMBs generally do not have the IT resources (knowledge or funds) to set up WPA2 Enterprise and MDM systems, so rely upon WPA2 Personal (i.e. passphrase) for Wi-Fi security of their business.  Most SMBs also have fairly liberal bring-your-own-device (BYOD) policies, and it only takes one user with one device sharing the Wi-Fi credentials to compromise the security of the network.   To complicate matters further, most consumer and IoT network devices may not even support WPA2 Enterprise.

So what are SMBs to do?  There are limited options:

• VLANs:  Segment your business network from your guest network, and only allow BYOD on your guest network (http://www.emperorwifi.com/2015/05/vlans-why-you-always-want-to-use-them.html).   This may require some network hardware as well as configuration upgrades, and may not even be practical for some businesses.  This also won’t completely protect you if you need some of those BYOD devices on your corporate network for your daily operations.
  
• PPSK:  Implement a Wi-Fi solution with personal pre-shared key (PPSK).  Unfortunately, there are only a few enterprise AP vendors (i.e. Cisco, Aerohive, Ruckus) that offer this functionality, and while I’m sure they all want to sell in the SMB space, their pricing and complexity are generally prohibitive for the SMB market.  Devin Akin has a good blog on PPSK and its relevance to IoT (http://divdyn.net/iot-fly/). 

The reality is that both VLANs and PPSK will ultimately be required.   AP vendors who focus on the SMB market generally support VLANs today and will ultimately offer integrated PPSK solutions.  Such solutions may be slow to appear, however, so I wouldn't be surprised to see one or more plucky startup firms try to fill this security void.  Watch this space.

Given the trends of more Wi-Fi Passphrase sharing applications, we need to accept that passphrase sharing is part of the new world order, and that WPA2 Personal is no longer sufficient  for the needs of SMBs or even for consumers who want to keep their network resources private.