[OpenWireless Tech] Eventual (long term) solutions

[Davidfine]

Exchanging keys over an untrusted channel is impossible without a 
mutually trusted third party. WPA actually does give different keys to 
each client, but the handshake is done with the PSK everyone knows. So 
if an attacker with the PSK observes the handshake (or can trigger one), 
the game is lost. It's not because the ieee is dumb, it's because 
<intractable problem>.

I don't think that's a deal breaker here, because you can't trust the AP 
not to snoop even if the phy layer is secured. You'd still want SSL for 
everything. But it's a fun excercise, so let's do it:

The goal is something that facilitates key exchange, doesn't require an 
account anywhere, and doesn't rely on new protocols.
It relies on a third party that both the Client and the AP trust, but 
that third party can't know anything about the client or AP.

1. Client connects to open wifi, lands on a captive web portal operated 
by the AP. The user clicks "I want to secure this WiFi connection". 
(Clicking 'no' makes the AP fall back on unrestricted open WiFi).
2. AP talks to TPP over SSL (hence the Trusted part). TPP returns a new 
SSID name, a 12 char PSK, and a random string ie. gBiX73AAuuB
3. The AP sets up a new SSID with the given SSID name and WAP PSK. Over 
its web interface it tells the client "click on 
https://trusted.com?session=gBiX73AAuuB to access the hotspot we made 
for you".
4. The trusted website tells the client "a hotspot has been created for 
you. SSID:(ssid) Password: (12 char PSK)
4a. Not so fast! Someone other than the client could intercept that URL!
4b. The TPP only gives the key out once. An attacker doesn't gain 
anything by hijacking the key, they could get one legitimately. All 
they've done is block the original person, who sees a notification from 
the TPP. Pretty boring.
4c. You could try to mitigate this by paying attention to BSSIDs or 
having an extra trust relationship between the AP and TTP, but meh.
5. If all goes well, the client connects to an SSID made just for them 
using a PSK nobody else knows.

In summary, if you trust the SSL cert you can exchange keys without the 
TPP knowing anything but the IP address of the AP. And the failure mode 
is no access, not insecure access. And it pretty much requires the AP to 
use OpenWRT. But the client needs nothing special. Also, captive portals 
suck.

Well, that was fun.
--DF


On 11/29/12 7:44 PM, John Gilmore wrote:
>>               I appreciate the improved security of WPA while lamenting
>> the disappearance of open WiFi.   ...
>> The eventual solution is probably something like an OpenID service for
>> 802.1X with access points advertising  their participation via 802.11u.
> Just because OpenID has "open" in its name does not mean it is good.
> It's a protocol for identifying yourself.
>
> If people (eventually) need to use OpenID to access an access point,
> then it isn't an open access point.  There is no point in
> authenticating yourself to an open port -- it would be like
> authenticating the AC power plug you stick in the wall socket, or
> authenticating the Ethernet cable you plug into a switch port.  We
> could build power sockets and Ethernet switches that way, but if we
> did, only niche markets would use them.  Everybody else would just
> keep using the open ones that don't hassle you when you try to use
> 'em.  (HDMI requires authentication every time it gets plugged in, due
> to its origins in Hollywood cartel DRM and the Intel monopoly, and
> it's caused endless hassle to consumers.)
>
> I think a better eventual solution is to provide a WPA-like protocol
> that doesn't assign the exact same key to everyone who supplies the
> same password (WPA does that, oops!).  If the protocol did
> Diffie-Hellman, then each node that connects would get a unique key,
> that is shared only with the access point.  This protocol could be
> used both on the WPA (restricted, personal) side of the access point,
> and on the open (unrestricted, public) side.  Any WiFi node that used
> this protocol would protect itself from its traffic being sniffed by
> anyone except the access point itself.  Doing this would require
> working in the 802.11 standards committees to define and find
> agreement on such a protocol, to be deployed in future WiFi hardware.
> WiFi keeps evolving quickly, with new generations every few years,
> so there is plenty of opportunity to improve the security protocols
> in subsequent generations.
>
> 	John
>
>
>
>
> _______________________________________________
> Tech mailing list
> Tech at srv1.openwireless.org
> https://srv1.openwireless.org/mailman/listinfo/tech
>