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)
No comments:
Post a Comment