There are many different wireless technologies that can be utilized in your IoT system but Wi-Fi will almost certainly make an appearance somewhere. With that in mind, we should probably talk a little about the level of security that is provided at Wi-Fi’s link layer. As developers we really are only interested in one thing – how much (if at all) does it help my security? The tl;dr version is that Wi-Fi link layer security is probably a nice to have but cannot be relied on as a security measure. Let’s discuss it a little more to find out why.
The first major drawback is that Wi-Fi link layer security will only provide encryption to packets sent within the wireless network. If your devices are communicating with a backend server the link layer security ends when the packets leave your Access Point (AP). So link layer security may stop a malicious eavesdropper listening locally to your wireless signals but offers no protection to compromised network entities between your AP and your backend server. For communication to backend servers you should really be looking at implementing SSL/TLS encryption.
The second major drawback (certainly from a developers point of view) with link layer security is that you have no control over it. A user’s Wi-Fi AP may be using WEP, WPA2 or even no security at all. Obviously the latter is the worst case scenario. However, as we’ll see WEP is completely broken so is pretty much as bad as no security. WPA2 while relatively secure does also have some vulnerabilities.
WEP (Wired Equivalent Privacy) was described in the first IEEE 802.11 (WLAN) specification. It was intended to provide privacy on a wireless network that was equivalent to a wired network. WEP uses the RC4 stream cipher to encrypt the plaintext data that is to be sent. As a key for the RC4 cipher WEP concatenates a 24-bit initialisation vector (IV) with the AP’s WEP key. A requirement of stream ciphers is that the same key should never be used twice. Clearly, the AP’s key will always be the same (with the exception of a manual change by a user). The inclusion of the IV was to ensure the RC4 ciphers input key satisfied this condition. However, 24-bits is not sufficient to guarantee this uniqueness. In fact, there is a 50% chance that the same IV will repeat after approximately 5000 packets.
In 2001, Scott Fluhrer, Itsik Mantin and Adi Shamir published details of an attack (also known as the FMS attack) that exploits the way IVs and RC4 is used in WEP and results in recovery of the WEP key.
Following the original FMS paper a number of other WEP cracking attacks were published. The speed of the key recovery using such an attack is dependent on the number of packets that can be observed, but can be achieved in as little as one minute. A paper by Erik Tews, Ralf-Phillipp Weinmann and Andrej Pyshkin outlines how this can be achieved for a 104-bit WEP key. Furthermore, you don’t have to be an encryption expert to craft a tool to carry out the attack. There are freely available software packages that can launch these kinds of attack. For example, Aircrack-ng. With such a flawed protocol and freely available cracking tools, WEP clearly offers no protection from a hacker with even limited computer skills.
WPA2 (Wi-Fi Protected Access 2) was created as a replacement to WEP. WPA does exist but was an interim solution for people migrating from WEP hardware that couldn’t support WPA2. WPA2 is a secure Wi-Fi link layer (of course there will be some caveats that we’ll look at now in a minute).
Setting up a WPA connection requires a four step process. Specifically these steps are, security policy agreement, 802.1x authentication, key derivation and distribution and finally data confidentiality and integrity (i.e. encrypting your data). For our purposes we don’t need to delve too deeply into the four step process; for the interested reader there is an excellent summary of WPA/WPA2’s four step setup in Wi-Fi security – WEP, WPA and WPA2 by Guillaume Lehembre. All we really need to know for this discussion is that WPA2 has resolved the critical flaws with WEP when it comes to key cracking. However, things would be a little too easy if we could just say WPA2 was unbreakable. There are still a number of attacks that can be attempted.
The first we’ll discuss is a brute force attack. For non-enterprise users WPA2 access points will likely use Pre-Shared Key (PSK) architecture. The PSK is generated from either a 256-bit string or an 8 to 63 character passphrase that is entered by a user. For short passphrases, say 8 character passphrases, a brute force attack is possible. However, as the passphrase is not the actual PSK there is some protection against such attacks. The PSK is calculated from the passphrase by applying the PBKDF2 key derivation function, using the AP’s SSID as the salt and 4096 iterations of HMAC-SHA1. Deriving the PSK from the passphrase in this manner requires time and ultimately slows down a brute force attack so that it is impractical. It’s worth noting that rainbow tables for common SSID and passphrase combinations do exist but these can be mitigated by an appropriate choice of SSID and passphrase.
The second, and more successful, type of attack we’ll discuss does not attack WPA2 directly. Rather an extension to Wi-Fi called Wi-Fi Protected Setup (WPS) is attacked. WPS was designed to help ease a user’s experience when attaching to a protected Wi-Fi network. WPS requires the user to simply enter an eight digit pin to join the network. It is this pin that will be the focus of a brute force attack designed by Stefan Viehböck. The eight digits comprise of seven digits of actual pin and a check sum digit. This should mean that there are 10,000,000 possible pins. However, the exchanges in WPS mean that the first four digits of the pin and the second four digits of the pin are verified in separate steps. By monitoring these verification steps there are at most 10,000 (first 4 digits) plus 1,000 (second 3 digits) possible pins and a brute force attack becomes much more feasible.
As we indicated during the introduction Wi-Fi link layer security might be a nice to have but realistically cannot be guaranteed to add any security to your IoT device. With that in mind, as IoT developers Wi-Fi link layer security shouldn’t be relied on to keep your users’ data safe. Other methods such as SSL/TLS encryption can be relied upon. We’ll also be looking at other security measures in future posts in our security series.