Security Bits Logo

Security Bits – 22 October 2017

Security Medium 1 – WPA WiFi Encryption Develops KRACKs

This week started with a big security news announcement (responsibly disclosed, which is nice). Security researchers at the Belgian university KU Leuven revealed a collection of related attacks against the WPA2 protocol (WiFi Protected Access version 2). The problem at the root of these attacks was not related to any specific implementation of the spec, but with the spec itself, so every manufacturer who implemented the spec correctly would have introduced these vulnerabilities into their WiFi drivers. Because you have to give a bug a fancy name to get any media attention these days, it was given the somewhat strained pseudo-acronym KRACKs, from key reinstallation attacks.

We’re not going to go into the technical minutia here, but I have included links to some good explanations below. I do want to give a high-level overview of the problem though.

The first technical point to note is that WPA2 doesn’t use your actual wireless network password to encrypt your wifi traffic. Your WiFi password (AKA your pre-shared key, or PSK) is only used to authenticate you to the access point (and it’s only of the authentication mechanisms supported by WPA) – once the access point has determined that you should be allowed to join the network it negotiates a short-lived device-specific encryption key with your device. This negotiation is known as the WPA 4-way handshake, and the problem discovered is in step three of that negotiation. This means that it affects both variants of WPA2 – the kind used in home routers (WPA-Personal AKA WPA-PSK), and the kind used in larger organisations (WPA-Enterprise) where users authenticate to wifi using some kind of centralised user account (often from AD). It also means that what gets exposed is not your actual WiFi password, but, the temporary encryption key. So, attackers do get to decrypt all the packets flowing between your device and your wireless access point, but they don’t get your WiFi password.

The problem discovered with the third step of the three-way handshake is that it’s possible for an attacker to cause a so-called cryptographic nonce (a pseudo-acronym from number used once) to be re-used. This is a massive security no-no. Literally, the entire point of a nonce is that it should never ever ever be re-used, ever. To quote Wikipedia:

In cryptography, a nonce is an arbitrary number that may only be used once … it is often a random or pseudo-random number issued in an authentication protocol to ensure that old communications cannot be reused in replay attacks.

The effect of this bug is to allow an attacker to decrypt a bunch of the packets flowing between a wireless access point and a single client for a short period of time. The attack can, of course, be repeated over and over again, so that short time isn’t much of a silver lining. Each device on a WPA2 network negotiates its own temporary encryption key with the AP, and they are all different, so an attacker does not get to see all the traffic on the entire network, just the traffic flowing to the single client they exploit. It’s vital to note that this is not a remote attack – attackers needs to be within WiFi range of their victims.

A good way to think about this bug is that until you patch your devices, every Wifi network has just become like hotel or coffee shop WiFi – everything that’s not run through a VPN or otherwise encrypted (e.g. with properly configured HTTPS or TLS) can be seen by attackers.

Finally, the fix for this problem is a small tweak in the WPA2 protocol for WiFi clients (or WiFi supplicants to use the official WPA jargon). This means that OS and device vendors need to tweak their Wifi client code to follow the new spec.

Because the bug involves WiFi, initial media attention fixated on WiFi routers, and how it would be impossible get firmware updates rolled out to all routers. This coverage completely missed the key point – what’s needed are client patches! As the hours went by this reality slowly began to sink in, and media coverage shifted to the real issue – getting updates onto all our computers, tablets, phones, and most troublesome of all, all those other devices that now live on our networks like our smart TVs, our games consoles, and our IoT devices.

What does muddy the water a little bit is that there are some scenarios in which WiFi access points behave as WiFi clients. In those scenarios, a firmware update is required. The two most common such scenarios are where one AP is used as an extender for another, and where multiple Apps are connected together into a mesh network. If either of those scenarios applies to you, then you absolutely need to get updates onto your access points. If you just have a single wireless router then it’s very unlikely it ever acts as a WiFi client, so fixating on getting your router patched is a waste of time an energy you should be devoting to the mammoth task of getting all your other devices patched!

Another subtlety is that some versions of Android misimplement the old spec in a spectacularly bad way – they re-set the encryption key to all zeros when part of the handshake is repeated, effectively removing the encryption completely! This über-bug only affects Android 6 and up, so Marshmallow, Nougat & Oreo.

Each device manufacturer will need to release an update to address this, and I can’t even begin to draw up a list of all the devices and whether or not there is a patch for them. What I can do is share what I know about the major OSes:

  • Windows – a fix was included in the October Patch Tuesday updates
  • macOS, iOS, watchOS & tvOS – not vulnerable because Apple didn’t completely/correctly implement the original buggy spec. Apple are working on an update that will implement the new non-buggy spec properly, and that’s already in beta.
  • Android – the bug was fixed as part of the October security update from Google, but the usual problems apply getting that fix out to all Android devices.
  • Linux – patches were available at the time the announcement was made


Security Medium 2 – ROCA

Security researchers have found a catastrophic bug in the firmware used by Infineon-made Trusted Platform Module (TPM) chips. These chips are used both on PC motherboards and, in smart cards. TPM is an international standard for dedicated cryptographic micro-controllers. They can securely generate and store cryptographic keys, and perform encryption and decryption on behalf of the devices they’re incorporated into. Basically, these are similar devices to Apple’s Secure Enclave, but more generic.

There are lots of uses for TPMs, but I want to draw particular attention to two common use-cases:

  1. Some nations have national ID cards with the ability to digitally sign documents. These smart cards obviously need to securely store cryptographic keys, so, they use TPMs.
  2. Disk encryption relies on the secure storage of cryptographic keys, so, Microsoft’s BitLocker uses TPMs to store disk encryption keys.

In theory, public/private key pairs generated by TPMs for asymmetric encryption should be very robust, and very secure. After all, we are talking about dedicated crypto hardware here! The whole point of asymmetric encryption is that it should be effectively impossible to derive the private key from the public key (i.e. it should take longer than the age of the universe to do).

And that’s where the ROCA vulnerability comes in. BTW, in case you’re wondering about the name, it stands for Return Of Coppersmith’s Attack.

It’s been discovered that due to a bug introduced into the firmware for Infineon TPM chips in 2012, many of the key pairs generated by the devices are millions of times easier to crack than they should be. Rather than taking multiples of the age of the universe to crack, a single CPU can do the job in a few months. Throw some cloud computing at the problem or a bank of high-end graphics cards, and you’ll get there even quicker! If you want to think of computing power in terms of dollars, then it would cost you $76 to break an affected 1024-bit key pair and $40,000 for a 2048-bit key pair using Amazon’s AWS cloud services.

Not all key pairs generated by the affected Infineon TPMs are vulnerable, but, given a public key, it’s possible to determine if it belongs to a vulnerable key pair in a matter of milliseconds. This means attackers can know up-front whether or not any key is worth the investment to crack.

Recovering from this bug is a two-step process. Firstly, the firmware in the TPM needs to be updated, and secondly, all the weak key-pairs need to be replaced with newly generated secure key pairs. You’ll see this second step referred to as re-keying.

Dealing with patching and re-keying national ID cards is a government problem, but dealing with weak BitLocker encryption is a problem regular old Windows users will need to tackle.

If you’re a Windows user who uses BitLocker you’ll need to start by trying to figure out if your computer contains a vulnerable Infineon TPM, and if it does, you’ll ideally need to get a firmware update form your computer’s hardware manufacturer. Once your firmware is patched, you’ll need to re-key BitLocker. If there’s not firmware patch available for your computer for whatever reason, all is not lost. IT’s possible to use software to generate your own BitLocker key pair, and use that instead of one generated by your TPM.

Many PC manufacturers including HP, Fujitsu, Lenovo, Acer, Asus, LG, Samsung, and Toshiba have released firmware updates, and Microsoft included related updates in this month’s Patch Tuesday updates.

I couldn’t possibly give detailed instructions in a situation like this – there are just too many permutations of hardware and OSes and configurations, so the best I can do is list some potentially helpful links that I’ve come across during my research.


Notable Security Updates

Notable News

  • Recent tests by security firm NSS labs found that Microsoft’s Edge browser protects users from more phishing attacks than Chrome or FireFox —… &…
  • Google have announced the new Advanced Protection Program – optional extra protection aimed at those at high risk of cyber attack. The price? Significant inconvenience and the cost of two hardware tokens —…
  • Google have announced that they are making changes to their AdWords product so it meets Apple’s guidelines for not being blocked by Safari’s Intelligent Tracking prevention. The end-result should be a better balance between measurement of ad effectiveness and user privacy —…

Suggested Reading

Palate Cleansers

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top