Five tips for protecting against wireless KRACK
BlogFebruary 08, 2018
The recent KRACK (Key Reinstallation Attacks) attack on the Wi-Fi WPA2 security protocols (CVE-2017-13077 through CVE-2017-13088) highlights the requirement to actively maintain and update embedded systems, especially long-life systems deployed in hostile environments.
KRACK is interesting because it is a flaw in a mature, widely used security protocol. KRACK exploits a flaw in the four-way handshake Wi-Fi devices use to establish encrypted communications using WPA2. Fortunately, there is a backwards-compatible fix for this vulnerability; patching either end of the Wi-Fi link fixes the problem.
Rather than going into the details of KRACK, I would like to use this as a case study – and a lesson plan – for those tasked with managing connectivity and embedded systems.
Problems will be found in all systems
First, problems will be found in all systems. Increasing computing power allows crypto algorithms and key lengths to be attacked. We have seen this in everything from the deprecation of the old DES encryption standard to the evolution of RSA key lengths to the currently recommended 2048-bit or longer keys. Even with a secure algorithm, implementation flaws and novel methods of attack can create vulnerabilities. Consider the various weaknesses discovered in the OpenSSL code as one example. Communications protocols may have weaknesses which may only be discovered after years of use, such as the Wi-Fi KRACK, which affects billions of devices.
Plan for failure plus remediation and updates
The biggest lesson of KRACK is that you must plan for failure and have a way to remediate and update your systems. Period. No exceptions. Sitting on my desk is a Wi-Fi lightbulb – it cost less than $20, with a full Wi-Fi stack that connects to the network. This device is vulnerable to the KRACK attack and will never be updated – the only way to remediate the exposure is to throw it away. (I should note that this lightbulb has other security holes, which is why it is sitting on my desk rather than screwed into a socket.) While somewhat plausible for low-cost consumer devices, discarding a working device is a poor approach that is completely unacceptable for any significant system. In contrast, vendors of Wi-Fi routers and access points, cellphones, tablets, and laptops have quickly released patches for KRACK. (Have you updated all of your Wi-Fi devices yet?)
A vital part of patching is knowing what systems need to be patched. You need a way to tell what is installed on a system and whether it is vulnerable. System scanning needs to cover what software is installed, the versions, and configuration. Many system-management tools provide this capability. Even embedded systems need the ability to be scanned and remediated after deployment.
Encrypt important communications
Yes, WPA2 encrypts data – but only for the Wi-Fi link. Full end-to-end encryption is needed, such as that provided by SSL/TLS (please use TLS 1.1 or 1.2 and prevent session downgrades to lower versions) or a VPN [virtual private network]. The applications running on an embedded system should be responsible for their own encryption rather than trusting the network to encrypt itself. This means that the application stack should be using a standard supported encryption mechanism like SSL/TLS or a VPN and ensuring that it is properly configured, not that the application needs to include encryption directly inside the application. If you do include crypto inside an application, use standard cryptopackages and libraries. Never try to build your own cryptoimplementation; that doesn’t end well...
Maintain tight access control
A mechanism is needed to detect, identify, authorize, and enroll all devices attempting to connect to your network. Ironically, access control is a major part of WPA2, using the “Wi-Fi password” as a shared secret. WPA2 actually does this rather well, and continues to do it well after being patched for KRACK. Other tools are available for other interfaces, ranging from simple Bluetooth pairing to complex attestation using Secure Boot or Trusted Boot for servers.
Exploiting communication vulnerabilities requires access. With Wi-Fi KRACK, this means being within a few hundred feet of the access point. This is actually a good thing; rather than allowing remote exploits, KRACK requires you to be physically close to your target.
Use a hard-wired Ethernet connection
This has been recommended by many sources as an effective way to remediate KRACK, especially for desktop and laptop systems. This could be as simple as a desktop Ethernet switch and some patch cables to use temporarily until you can patch your devices, or it could be a wired building with Ethernet drops in each office and laptop docking stations.
When considering system design, remember the key differences between and benefits of wireless and wired devices. Wireless devices are easy and inexpensive to install, easy to move, and easy to add more devices and connections. Wired devices typically cost more to install, are difficult to move, may be difficult to add more devices (since more communications ports are required), and are usually faster, more reliable, and more secure. Wired interfaces require direct physical access for communications, and typically emit little or no electromagnetic radiation.
Communications is a key part of most embedded systems. While KRACK is specific to Wi-Fi WPA2, similar concerns apply to all forms of wireless interfaces – actually to all interfaces, wired or wireless. Enabling the security and integrity of communications is a part of the design, implementation, and life cycle management of these systems.
Russell Doty is a technology strategist and product manager at Red Hat. Readers may connect with Russell at rdoty@redhat.com.
