Addressing the Wi-Fi KRACK Vulnerability for IoT and Connected Products

Published by Barbara Nelson October 16, 2017

Another day, another security vulnerability.

We all woke up today to read about a new security vulnerability, the KRACK attack ( and the first question on every product developer’s mind is how does this impact my products and what do I have to do to address this vulnerability.

First, a little background on the KRACK attack. The KRACK attack uses a vulnerability in the WPA2 protocol during the key negotiation phase, which enables a rogue AP to intercept traffic between the device and the real AP, and then trigger the device to reinstall a known encryption key. Once the device reinstalls that key (which is known to the rogue AP), traffic that is being intercepted by the rogue AP can be decrypted by the rogue AP. Unfortunately, because this vulnerability is part of the WPA2 standard, every correctly-implemented Wi-Fi stack has this vulnerability. Linux and Android products using version 2.4 and above of the wpa_supplicant are even more vulnerable, as the exploit is easier to carry out on that implementation.

One thing that mitigates the risk for this vulnerability is that much of the traffic on a Wi-Fi network is additionally protected by being within a HTTPS tunnel. The second part of the vulnerability relies on social engineering, where the user does not notice that they are being redirected to a HTTP server masquerading as the HTTPS server they were trying to reach, so that data between the device and the server is sent as clear text rather than being encrypted.

For a connected product, the risks are a little different, as we aren’t likely dealing with end users not noticing that they got redirected to an insecure website. That makes this vulnerability easier to address. If the connected product communicates with a secure web server (e.g. your cloud, or the Cirrent cloud) make sure that the product verifies that the traffic is going over HTTPS, and verify the server certificate before exchanging any information. Drop the connection if you were expecting a HTTPS connection and got a HTTP connection instead, and you’ll avoid having your content exposed to a rogue AP. In our ZipKey client, we always validate the server certificate when connecting to our Cirrent servers, and never send any traffic over a HTTP connection.

So, the short checklist for a developer of a connected product is:

  1. Upgrade your Wi-Fi stack to a version that addresses this issue as soon as a patch is made available. Many of the Wi-Fi stack providers have already issued patches to address this issue.
  2. Double-check all your HTTPS calls to make sure that they are over HTTPS, not HTTP, and that they validate the server certificate on every connection.  If you're using MQTT or another messaging protocol, make sure you are doing certificate validation in your SSL/TLS session. 

These are best practices that we should be following all the time, and a security vulnerability like this just reminds us to confirm that we are following security best practices in all of our connected products.

If you have questions or comments, please leave them in the comments below, or email us: