Based on what I read on one of their FAQs, it is not as good as a secure enclave, but it is quite a bit better than simply not providing a show password option.
The password is not stored on the devices of the people you share with. It's stored on Microsoft servers. When the device someone you have shared with notices that a network you've shared is available, it gets the key to connect, then presumably forgets it.
I wonder if it is possible to do better? The idea would be that when setting up the connection (so, setting up session keys and authenticating) the device could pass these packet through to Microsoft's server. Microsoft's server could then calculate the response packets and give them to the device to relay to the access point. When the connection set up is all done, Microsoft's server could pass the session key to the device, and subsequent packets would be handled entirely on the device.
There are two (at least) things that could torpedo this kind of approach. (1) the protocols might work in such a way that you cannot hand off the setup/authentication, or they might require frequent enough re-keying that spotty cell access could prevent keeping wifi working, and (2) the connection setup and authentication might be handled in firmware that does not provide a low enough level interface to do the fiddling needed.
Reading the 802.11-2012 spec, one could send the ANonce to the server, and the server then could generate a SNonce and construct the PTK from the secret PMK stored on the server. This would be secure because the nonces are supposed to be random. I think group key change also depends only on the PTK. This would still be more secure than open WiFi because it would not possible to decrypt packets to/from from other stations with a different SNonce.
You could extract the handshake nonces and do this easily enough. It's fairly pointless though because WPA2 uses a weak hash function, so your "contacts" would still be able to intercept enough to attempt to bruteforce your password.
Also this entire thing seems dumb. If you need to connect to Microsofts server before you have wifi then you already have data.
I think it is to deal with data caps. And brute force is always possible if one has the 4-way handshake and the password is only useful if you are near enough to actually connect to the network. AFAIK the PSK uses PBKDF2.
>When the device someone you have shared with notices that a network you've shared is available, it gets the key to connect, then presumably forgets it.
So you still need minimal internet connectivity in the first place In order to ask MS' servers? Suddenly sounds less useful for things that aren't phones.
The password is not stored on the devices of the people you share with. It's stored on Microsoft servers. When the device someone you have shared with notices that a network you've shared is available, it gets the key to connect, then presumably forgets it.
I wonder if it is possible to do better? The idea would be that when setting up the connection (so, setting up session keys and authenticating) the device could pass these packet through to Microsoft's server. Microsoft's server could then calculate the response packets and give them to the device to relay to the access point. When the connection set up is all done, Microsoft's server could pass the session key to the device, and subsequent packets would be handled entirely on the device.
There are two (at least) things that could torpedo this kind of approach. (1) the protocols might work in such a way that you cannot hand off the setup/authentication, or they might require frequent enough re-keying that spotty cell access could prevent keeping wifi working, and (2) the connection setup and authentication might be handled in firmware that does not provide a low enough level interface to do the fiddling needed.
reply