7

I was looking at this guide to setting up a wifi connection on a modern linux system (specifically raspbian, but I assume the steps are similar in other linux systems) with only a command-line interface. The guide mentioned that the PSK could be stored as a pre-encrypted 32 byte hexadecimal number, but also mentioned that a plaintext SSID and PSK will be used to connect. Further, the wpa_passphrase tool seems to encrypt the PSK using the SSID (unless I am misinterpreting the tutorial).

If an attacker gained access to this wpa-supplicant configuration file, it seems like he could just use the SSID (stored there in plain text) and knowledge of the wpa_passphrase tool's encryption algorithm to decrypt the PSK, giving no more security than storing a plain-text PSK in the file. Is this not the case, and why?

jaredad7
  • 205

2 Answers2

8

The PSK isn't an encrypted version of your passphrase; it's a hashed version of your passphrase. Specifically (if I remember correctly), the PSK in WPA2 is the output of PBKDF2(passphrase) using the SSID as a salt.

The difference is that ciphers are reversible, hashes are not. The PSK is actually directly usable as the WPA2 network key, without any decryption at all, but it cannot be reversed to find out the original passphrase.

This only provides mild security on its own, but if you frequently rotate the passphrase (e.g. MyLittleWifi42 → MyLittleWifi43 → MyLittleWifi44), then someone having just the hashed PSK has no way of guessing future passphrases. Similarly, renaming the network also invalidates all old PSKs.

(Note: As far as I know, this method will no longer work with WPA3-SAE, which requires the client to have the original passphrase. Storing just the PSK would limit you to WPA2 only.)

grawity
  • 501,077
2

In wireless networks protected by WPA-PSK / WPA2-PSK ("WPA2-Personal"), a 256-bit preshared key (PSK) is used as pairwise master key (PMK) from which encryption keys are derived to secure the wireless connection. The 802.11 standard recognizes that it is difficult for users to correctly enter 64 hexadecimal characters and therefore defines a passphrase-to-PSK mapping that combines the passphrase and SSID using PBKDF2:

PSK = PBKDF2(passPhrase, ssid, 4096, 256/8)

The passphrase is between 8 and 63 ASCII-encoded characters which makes it possible to differentiate between passphrases and PSKs. The passphrase and SSID will be hashed 4096 times using the HMAC-SHA1 function in PBKDF2 to produce a 256-bit PSK.

If you configure wpa_supplicant with a passphrase, it will internally spend some cycles to compute the 256-bit PSK for you. Indeed, both the passphrase and PSK can be used to connect to wireless networks. So if your configuration file is leaked, then both keys would be as insecure.

One minor benefit of storing a PSK instead of passphrase is that it adds some privacy. Consider passwords like ILoveMyMom2000 or EindhovenDeGekste, both passwords could reveal some information about people. However, if your password is easy to guess from a dictionary, then someone could "reverse" the PSK by guessing the right password.

With WPA3-SAE ("WPA3-Personal") using the Simultaneous Authentication of Equals (SAE) password-authenticated key exchange protocol, the ASCII-encoded passphrase is directly used without prior processing. The output of SAE is a fresh PMK that is independent from the PSK. There is no longer a need to expand the password to a longer 256-bit PSK, so the wpa_passphrase tool should not be used with it.

Out of curiosity, I tried setting up a WPA3-Personal network using hostapd and a psk set to the 64 hexadecimal character "PSK" output from wpa_passphrase. While an Android client is able to connect using the original passphrase, an iPhone client failed. Android uses wpa_supplicant which shares the same codebase with hostapd. Perhaps wpa_supplicant still expands the original password using PBKDF2, even in WPA3-SAE mode. This sounds like an implementation bug to me, or a liberal interpretation of this part of the specification:

Representation of a character-based password in another character set or use of a password preprocessing technique (to map a character string to a binary string) may be agreed upon, in an out-of-band fashion, prior to beginning SAE.

Lekensteyn
  • 6,982