Why can't Wifi be secured assymetrically?

Question

Why couldn't we switch from AES to something asymmetric? Then a private key doesn't need to be shared with the client; rather just share a public key with them.

Answer 1

The concept

I will assume you mean a hybrid cryptosystem, since encrypting everything with asymmetric algorithms would be slow for embedded devices like (cheap) routers. TLS (used in HTTPS) uses the same thing: public key gets sent to the browser, they use that to exchange a secret key (randomly generated for each connection), and from there use AES or ChaCha20 to exchange data (encrypted using the random key).

In WPA2-PSK networks, you can decrypt the traffic from all clients if you know the pre-shared key (the PSK) and were able to capture the handshake that took place at the beginning of a connection. Why do we not use asymmetric encryption, which allows only the recipient to decrypt our message? It would work like this:

1. Client connects to the WiFi access point (AP)
2. AP sends public key to client
3. Client generates a random key, encrypts it with the PSK, encrypts that with the public key, and sends it to the AP
4. AP decrypts the message with its private key and consequently with the PSK.
5. Now, they both know the random key, to be used for symmetric encryption.

One cannot setup an AP without knowing the PSK, since they would never be able to decrypt the random key.

The issue: public key verification

There is one issue here: how do you know that you received the correct public key upon connecting? Anyone could send you a public key, also an attacker, and your client would be encrypting the random key with the attacker's public key. The attacker can decrypt your traffic, and relay it to the AP, so you have no idea that you are being intercepted.

Why a CA system can't be used

In HTTPS, this is solved by the CA system, where there are trusted third parties whom can sign your public key. Anyone connecting to the website will check that it is signed by a trusted third party. This works because a CA can easily check whether someone owns a domain: "I will only sign your certificate for example.com, if you put the code 1ZTHrM5OM14fe2ce in example.com/verification". This is not possible for a WiFi network since it requires physical proximity, and there is no concept of having a unique domain name.

Checking the fingerprint

SSH solves this by showing the fingerprint to the client, something along the lines of "192.168.1.1 has the fingerprint SHA256:1OBS2zY..., do you wish to continue?" If you continue, it will store the fingerprint (FP) and the IP address or domain that you were connecting to, so it can just check that it didn't change since last time.

This is also possible with WiFi (after first use, the FP would be stored with the SSID). The trouble is that the full FP needs to be communicated to the client, and the user needs to check each byte. Do you see your grandparents carefully checking whether Wa3rQOGlqo matches the FP published by the owner of the network? If you check only a few bytes in the beginning and/or end, it is trivial to generate a public key whose FP matches the beginning and/or end. It also makes it more difficult to replace your AP, since you'd need to transfer the private key (or re-configure each connected device to trust the new FP).

What is the point of this again?

But why bother? The AP already proved that it knows the PSK. Why do we want to have an additional verification?

Well, the whole point of using asymmetric crypto rather than symmetric crypto, is preventing clients from reading each other's traffic. Anyone with knowledge of the PSK can setup a fake AP and intercept traffic. Therefore it is necessary to employ a scheme which verifies that the correct public key was used.

Conclusion

Because there is no user-friendly way of doing this, I assume. But I don't know of any literature in which this was discussed and rejected. Or any proposed standards that never got to widespread use.

It could definitely be done as described above if people are willing to check fingerprints, but it might be easier to just connect a VPN if you want to protect your traffic.

Answer 2

AES is very fast, even in software it's not bad, but with hardware acceleration it's pretty easy to keep up with high data rates without having crazy huge hardware acceleration blocks.

You can lookup speed benchmarks for various crypto operations - you'll note most of the time RSA/ECC are given in time to perform a single decryption operation, or a single key exchange.

To give you a bit of a stick in the mud, we can look at hardware IP cores from the same vendor and speed/resource usage. I'll use IPcores.com as they have both types of cores, it's just a random company I used as an example. In hardware I'll use their published "number of gates" to give you some scale - more gates means more hardware needed in the chip = more expensive.

For An ECC Core from IPCores.com it's about 10K gates. For An AES Core from IPCores.com it's about 3K gates.

The AES core advertises 0.8bits/clock, so for example running it at 100MHz would give you 80Mbits/sec (10MByte/sec) throughput. You could easily go way faster than that or run a larger (but processes more at once) core to achieve almost any bit rate you need, as that 3000-gate core is the slowest option.

The ECC core doesn't publish a bit rate - but does say about 5000 point muls/second (the core isn't a full ECC implementation, so there is other stuff needed). But it should give you a feeling this isn't even remotely close to the required performance for doing actual data decryption at full data-rate needed.

The other issue associated with size/speed tradeoff is that a larger core running faster is going to be a huge power hog, so you'll also have issues w.r.t battery power consumption.

But I think if you start doing some experiments with asymmetric crypto speeds it will help you understand why we don't use asymmetric crypto everywhere, and just to exchange some critical information before switching to a symmetric cipher.

Answer 3

Because wireless devices have lesser amount of RAM and storage, it would be tough to perform key management operations that a re required for an asymmetric encryption algorithm to work.