This week started with a big security news announcement (responsibly disclosed, which is nice). Security researchers at the Belgian university KU Leuven<\/em> revealed a collection of related attacks against the WPA2 protocol<\/a> (WiFi Protected Access<\/em> 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<\/em>.<\/p>\n We\u2019re 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.<\/p>\n The first technical point to note is that WPA2 doesn\u2019t use your actual wireless network password to encrypt your wifi traffic. Your WiFi password (AKA your pre-shared key<\/em>, or PSK) is only used to authenticate you to the access point (and it\u2019s only of the authentication mechanisms supported by WPA) \u2013 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<\/em>, and the problem discovered is in step three of that negotiation. This means that it affects both variants of WPA2 \u2013 the kind used in home routers (WPA-Personal<\/em> AKA WPA-PSK<\/em>), and the kind used in larger organisations (WPA-Enterprise<\/em>) 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\u2019t get your WiFi password.<\/p>\n The problem discovered with the third step of the three-way handshake is that it\u2019s possible for an attacker to cause a so-called cryptographic nonce<\/a> (a pseudo-acronym from number used once<\/em>) 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:<\/p>\n In cryptography, a nonce is an arbitrary number that may only be used once \u2026 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.<\/p><\/blockquote>\n 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<\/em> isn\u2019t 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\u2019s vital to note that this is not a remote attack \u2013 attackers needs to be within WiFi range of their victims.<\/p>\n 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 \u2013 everything that\u2019s not run through a VPN or otherwise encrypted (e.g. with properly configured HTTPS or TLS) can be seen by attackers.<\/p>\n Finally, the fix for this problem is a small tweak in the WPA2 protocol for WiFi clients<\/strong> (or WiFi supplicants<\/em> 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.<\/p>\n 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 \u2013 what\u2019s needed are client patches! As the hours went by this reality slowly began to sink in, and media coverage shifted to the real issue \u2013 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.<\/p>\n 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\u2019s 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!<\/p>\n Another subtlety is that some versions of Android misimplement the old spec in a spectacularly bad way \u2013 they re-set the encryption key to all zeros when part of the handshake is repeated, effectively removing the encryption completely! This \u00fcber-bug only affects Android 6 and up, so Marshmallow<\/em>, Nougat<\/em> & Oreo<\/em>.<\/p>\n Each device manufacturer will need to release an update to address this, and I can\u2019t 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:<\/p>\n Security researchers have found a catastrophic bug in the firmware used by Infineon-made Trusted Platform Module (TPM)<\/a> 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\u2019re incorporated into. Basically, these are similar devices to Apple\u2019s Secure Enclave<\/em>, but more generic.<\/p>\n There are lots of uses for TPMs, but I want to draw particular attention to two common use-cases:<\/p>\n 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).<\/p>\n And that\u2019s where the ROCA vulnerability comes in. BTW, in case you\u2019re wondering about the name, it stands for Return Of Coppersmith\u2019s Attack<\/em>.<\/p>\n It\u2019s 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\u2019ll 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\u2019s AWS cloud services.<\/p>\n Not all key pairs generated by the affected Infineon TPMs are vulnerable, but, given a public key, it\u2019s 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.<\/p>\n 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\u2019ll see this second step referred to as re-keying<\/em>.<\/p>\n 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.<\/p>\n If you\u2019re a Windows user who uses BitLocker you\u2019ll need to start by trying to figure out if your computer contains a vulnerable Infineon TPM, and if it does, you\u2019ll ideally need to get a firmware update form your computer\u2019s hardware manufacturer. Once your firmware is patched, you\u2019ll need to re-key BitLocker. If there\u2019s not firmware patch available for your computer for whatever reason, all is not lost. IT\u2019s possible to use software to generate your own BitLocker key pair, and use that instead of one generated by your TPM.<\/p>\n 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\u2019s Patch Tuesday updates.<\/p>\n I couldn\u2019t possibly give detailed instructions in a situation like this \u2013 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\u2019ve come across during my research.<\/p>\n 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 […]<\/p>\n","protected":false},"author":4,"featured_media":13191,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[147,214],"tags":[1941,1942,50,569,780,1939,1940],"class_list":["post-13188","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-posts","category-security-bits","tag-krack","tag-roca","tag-security","tag-security-bits","tag-wifi","tag-wpa","tag-wpa2"],"jetpack_featured_media_url":"https:\/\/www.podfeet.com\/blog\/wp-content\/uploads\/2017\/10\/security_bits_logo_300px.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts\/13188","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/comments?post=13188"}],"version-history":[{"count":4,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts\/13188\/revisions"}],"predecessor-version":[{"id":13193,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts\/13188\/revisions\/13193"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/media\/13191"}],"wp:attachment":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/media?parent=13188"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/categories?post=13188"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/tags?post=13188"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Links<\/h3>\n
\n
Security Medium 2 – ROCA<\/h3>\n
\n
Links<\/h3>\n
\n
Notable Security Updates<\/h3>\n
\n
Notable News<\/h3>\n
\n
Suggested Reading<\/h3>\n
\n
\n
\n
\n
Palate Cleansers<\/h3>\n
\n