5 ms·

From https://www.windowsphone.com/en-gb/how-to/wp8/connectivity/wi-fi-sense-faq https://www.windowsphone.com/en-gb/how-to/wp8/connectivity/w... > Your contacts

by NBo7I 11y ago

From https://www.windowsphone.com/en-gb/how-to/wp8/connectivity/wi-fi-sense-faq https://www.windowsphone.com/en-gb/how-to/wp8/connectivity/w... > Your contacts don't see your WiFi network password. > When you share network access, your contacts get Internet access only. How can they ensure these two?

MichaelGG 11y ago
They could require "secure enclave" hardware. But that'd need cooperation with the NIC, too, eh? Most likely they mean "we disable the show password option".
- ppuIndd 11y ago
  Let's assume that they have somehow secretly shipped this "secure enclave" with all machines that will support Win10, and that they have h4xXx0r proof-ed the code to make it impossible to RE the code and implement the protocol directly, presumably we'll still be able to emulate Win10 and have a virtual NIC which spits out the key when it's handed off to it.
  - MichaelGG 11y ago
    You won't be able to emulate the secure enclave, no. That'd sort of defeat the entire point. It is supposed to be impossible to RE the code for anything useful - the keys are encrypted using the public key of the secure enclave. You'd need to break the chip itself to win, and since Intel knows this, we can assume they'll make it incredibly hard. Of course, since MS wants this to work on current hardware, not "shipping sometime in the future" we can assume they aren't using Intel SGX. But in theory it's fairly strong DRM. https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx https://software.intel.com/en-us/blogs/2013/09/26/protecting...
  - deleted 11y ago
    [deleted]
- tzs 11y ago
  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.
  - yuhong 11y ago
    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.
  - nly 11y ago
    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.
    - yuhong 11y ago

by NBo7I 11y ago

MichaelGG 11y ago

They could require "secure enclave" hardware. But that'd need cooperation with the NIC, too, eh? Most likely they mean "we disable the show password option".

ppuIndd 11y ago
Let's assume that they have somehow secretly shipped this "secure enclave" with all machines that will support Win10, and that they have h4xXx0r proof-ed the code to make it impossible to RE the code and implement the protocol directly, presumably we'll still be able to emulate Win10 and have a virtual NIC which spits out the key when it's handed off to it.
- MichaelGG 11y ago
  You won't be able to emulate the secure enclave, no. That'd sort of defeat the entire point. It is supposed to be impossible to RE the code for anything useful - the keys are encrypted using the public key of the secure enclave. You'd need to break the chip itself to win, and since Intel knows this, we can assume they'll make it incredibly hard. Of course, since MS wants this to work on current hardware, not "shipping sometime in the future" we can assume they aren't using Intel SGX. But in theory it's fairly strong DRM. https://software.intel.com/en-us/blogs/2013/09/26/protecting-application-secrets-with-intel-sgx https://software.intel.com/en-us/blogs/2013/09/26/protecting...
- deleted 11y ago
  [deleted]
tzs 11y ago
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.
- yuhong 11y ago
  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.
- nly 11y ago
  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.
  - yuhong 11y ago