class: big, middle # ECE 7420 / ENGI 9823: Security .title[ .lecture[Lecture 23:] .title[Wi-Fi security] ] --- # Today ## Wi-Fi security ### WEP and its problems ### WPA and its future --- # Background .floatright[ | OSI layers | |------| | Application | Presentation | Session | Transport | Network | Data link | Physical ] What assumptions do we make on wired networks? -- What assumptions _should_ we make? -- ### Dolev-Yao assumptions * protocols should work on untrusted networks! -- * often want to control _access_ to a network -- * link-level privacy not a _bad_ idea (defence in depth) ??? Just like Kirchoffs never said that you _have_ to give the design of a cipher system to the adversary, Dolev and Yao don't say that we _have_ to let our adversary tap into our network routers' core software. Instead, they say that **we should design protocols as if this has happened.** --- # IEEE 802.1X .floatright[ <img src="https://upload.wikimedia.org/wikipedia/commons/1/1f/802.1X_wired_protocols.png"/> .caption[Source: Arran Cudbard-Bell via Wikimedia] ] ### Protected network access -- **Authentication:** who are you? -- **Authorization:** can you use this network? -- **Audit/accounting:** AAA or AAAA via RADIUS -- ... or Diameter -- **Other policy:** ever try to share the Memorial wired network via Wi-Fi? ??? At home, you can set your computer to act as a gateway and pass traffic from Wi-Fi clients through to the wired network. On the Memorial network, however, if you try to set your computer to be a Wi-Fi access point, you'll get a message saying that the network policy doesn't allow you to do that. That's because the wired network uses IEEE 802.1X to announce a "don't share me" policy. Question: how would that policy be enforced? --- # History ### IEEE 802.11 * 1997: let's make computers talk to each other without wires! -- * original plan for security: _wired equivalent privacy_ (WEP) ??? Providing equivalent security to wired Ethernet networks wasn't exactly a lofty goal, and yet it's a goal that wasn't reached. -- * not exactly successful --- # Background ### Are there any unbreakable ciphers? ??? We know that the one-time pad, if used with a random keystream, provides **perfect security** (a strong but provable claim!). -- ### Why is the a one-time pad impractical? ??? The problem with the one-time pad is that we have to **distribute a bunch of random keystream** to our communication endpoints. That's difficult to do without a global network of couriers, etc. So, instead, one thing we can do is try to **approximate a random keystream** using a keystream derived from a **stream cipher**. -- ### Stream ciphers ??? There are lots of good examples of stream ciphers: you can use a block cipher with a stream cipher mode like GCM, or you can use a purpose-designed stream cipher like [Salsa20](https://www.ecrypt.eu.org/stream/salsa20pf.html) or [Trivium](https://www.ecrypt.eu.org/stream/triviumpf.html). However, Wi-Fi predates many of these options, so it used... --- # RC4 ??? RC4 ("Rivest Cipher 4" or "Ron's Code 4") was designed in the 1980s; its design was initially kept secret by RSA Security (where the "R" stands for "Rivest"). This was a state-of-the-art algorithm designed by a famous cryptographer and used by a firm whose entire business is computer security. However, it wasn't subjected to critical external review because it was guarded as a **trade secret**. Like a lot of secrets, it eventually leaked and people started writing code to generate "ARC4" output (an algorithm that is 100% compatible with RC4 but which didn't suffer from the legal ambiguity associated with RSA's IP). -- Initialize 256B of internal state `S` from a _key schedule_ -- , then: -- <img src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/RC4.svg/500px-RC4.svg.png" align="right"/> ```pseudo i := 0 j := 0 while GeneratingOutput: i := (i + 1) mod 256 j := (j + S[i]) mod 256 swap S[i], S[j] i = (S[i] + S[j]) mod 256 K := S[i] output K end while ``` ??? Once RC4 gets going, it provides confusion via non-linear access to values that come from the current state. It also has diffusion, as values get swapped around within that internal state. So... good? The problem is that these properties only really apply **after the algorithm has gotten going** and **done some shifting**. The first few bytes of keystream largely depend on **a few bytes of the key**. --- # WEP and RC4 * frames encrypted w/RC4 using one of four pre-shared keys -- * problem: first few bytes of keystream depend largely on few bytes of key -- * if you learn first few bytes of keystream, you can get information about the key... but how? -- * protocol encapsulation and _framing_: much of plaintext's first byte(s) known ??? As we've seen in the lab and elsewhere, networking is full of **encapsulation**. For example, an HTTP packet has HTTP traffic (with HTTP headers) contained in a TCP packet (with TCP headers) which is contained in an IP packet (with IP headers) which is contained in a network frame (typically with Ethernet headers). That means that many of the bytes at the beginning of a network packet are **easily guessed** ― or even **fixed**. -- (see _FMS attack_&ast;) .footnote[ &ast; Fluhrer, Mantin and Shamir, "Weaknesses in the Key Scheduling Algorithm of RC4", in _SAC 2001: Proceedings of Selected Areas of Cryptography_, LNCS 2259, 2001. DOI: <a href="https://doi.org/10.1007/3-540-45537-X_1">10.1007/3-540-45537-X_1</a> ] --- # WEP cracking .centered[ <img src="https://www.researchgate.net/publication/318180928/figure/fig4/AS:667819544952837@1536231995263/Screenshot-of-Kali-Linux-terminal-emulator-with-the-acquired-WEP-key-using-aircrack-ng.jpg"/> ] --- # WEP and CRC * what's the point of a MAC? -- * WEP: CRC32 instead of MAC ― so what's the problem? -- ### CRC not designed with an adversary in mind -- ### CRC is linear: .center[ $$ \textrm{crc}(M\_1 \oplus M\_2) = \textrm{crc}(M\_1) \oplus \textrm{crc}(M\_2) $$ ] ??? Because the CRC is linear, I can know what bits of the CRC will change if one bit of the message gets flipped. Put more adversarially, if an attacker Mallory wants to flip a bit in a message, she knows **which bits of the CRC to flip** in order to make the CRC continue to match the message. This is very different from a **MAC**, in which an attacker modifying a message has no way to **generate a new MAC that will check out**. -- ... which composes poorly with a stream cipher! ??? This is still true when working with a message and CRC that have been encrypted with a stream ciphier (or one-time pad!). An attacker can flip ciphertext bits and "fix up" the CRC without needing to know **what the plaintext bits are**, only that they are flipping. --- # WEP integrity ### Not much! ??? So in WEP, an attacker could alter arbitrary bits within an encrypted packet and have the packet still accepted as valid. This is not good, especially given that we know where lots of data is located within ciphertext packets due to **encapsulation**. For example, suppose you wanted to alter a destination IP address to cause a Wi-Fi client to send data to you instead of its intended destination... if that destination address is well-known, you can! --- # ChopChop attack ### It gets worse! -- ### Wi-Fi APs as oracles ??? If you send a packet to an access point whose CRC doesn't match the message, the AP will respond with an error frame that is different from other errors. This allows an attacker to treat the AP as an oracle that distinguishes between "good CRC" and "bad CRC". If you take a previously-broadcast packet and retransmit _most_ of it, you can ask the AP "is this CRC good?" -- ### Chopping off bytes ??? This doesn't seem like much of a superpower until you remember that the relationship of the CRC to the message is linear, so it's possible to construct linear relationships among the bytes of the original frame, the shortened frame, the CRC bytes **and the missing byte**. By trying variations on the shortened frame's CRC, you can **figure out the value of the missing byte**. If you repeat this process, you can **decrypt the whole frame**. --- # WPA: Wi-Fi Protected Access ##### (stopgap, partial implementation of 802.11i) -- ### TKIP: Temporal Key Integrity Protocol * still uses RC4 (compatibility with old hardware) -- * better key scheduling (not just key+IV) stops _related key attacks_ -- * new encryption key every packet -- ### Message Integrity Code (MIC) --- # WPA2 ### IEEE 802.11i-2004 -- ### Mandatory AES-CCMP -- ### PSK or EAP ??? EAP (Extensible Authentication Protocol) uses the same RADIUS infrastructure as IEEE 802.1X, so you can plug it into your existing enterprise authentication infrastructure. --- # WPA-PSK ### Four-way handshake: $$ \begin{align} AP \rightarrow S &: N\_{AP} \\\\ S \rightarrow AP &: N\_{S}, MIC \\\\ AP \rightarrow S &: \left\\{ k\_{GTK}, MIC \right\\}\_{k\_{PTK}} \\\\ S \rightarrow AP &: MIC \end{align} $$ ??? The GTK (Group Temporal Key) is the key that's generally used for encryption on the wireless network. It can be changed periodically (it's a _temporal_ key). -- where $ k\_{PTK} = h \left( k\_{PMK} + N\_{AP} + N\_S + MAC\_{AP} + MAC\_S \right) $ ??? The Pairwise Temporal Key is used for this initial pairwise communication between the _station_ and the access point. It is derived from the Pairwise Master Key, which can be derived from a Pre-Shared Key (PSK) if there is "a passphrase" for the network, or can come from RADIUS in the case of EAP (see next slide). Note that "MAC" in this instance means "Ethernet MAC address", _not_ Message Authentication Code! -- ... from which **tons** of other keys are derived --- # WPA-EAP ### EAP: Extensible Authentication Protocol -- * Ethernet frame protocol defined by IEEE 802.1X (even wired) -- <img src="https://upload.wikimedia.org/wikipedia/en/thumb/f/f2/Eduroam_logo.svg/400px-Eduroam_logo.svg.png" align="right"/> * Allows authentication to be tunnelled to an external AAA server (e.g., RADIUS) -- ### Memorial: EAP-PEAP w/MSCHAPv2 --- # Modern WPA ### Moving to WPA3 * forward secrecy! * _zero-knowledge_ mutual authentication via PAKE -- * PAKE: _password-authenticated key exchange_ ??? There are a variety of PAKE protocols out there, all of which allow two parties to use a password to prevent middleperson attacks in something like Diffie-Hellman key exchange. -- SAE: _simultaneous authentication of equals_ (IEEE 802.11s) ??? Simultaneous Authentication of Equals is a protocol that also allows two parties to establish a key while proving to each other that they both know a pre-shared password (but without having to reveal any information about that password). -- * **Diffie-Hellman** (or, rather, a variant of it) strikes again! -- But [the game goes on](https://eprint.iacr.org/2019/383)... ??? The attack against the WPA3 handshake is one of those vulnerabilities that has to have a cute name ("Dragonblood") and a [shiny website](https://wpa3.mathyvanhoef.com). --- # Today ## Wi-Fi security ### WEP and its problems ### WPA and its future --- class: big, middle The End.