12 ms·

OpenWifiPass – Open-Source Implementation of Apple's Wi-Fi Password Sharing

232 points by jagged-chisel 6y ago

remram 6y ago
What does Apple's Wi-Fi Password Sharing do? Share the password between a user's device? With other users? Based on location, contacts?
- t0mas88 6y ago
  I think the main use-case is sharing the Wifi password from your iPhone to your Apple Watch or iPad. But it also works with people in your contacts if you are already connected to a network (let's say your home network) and a friend is trying to connect to that same network.
  - djrogers 6y ago
    Those 2 use cases are completely separate, and the one that’s being discussed here is the second one. The first is covered by iCloud Keychain sync.
- bberenberg 6y ago
  You connect to wifi in my house (or anywhere where I am connected to a password protected netwrok). If we both have BT enabled and are in each others contact list, I am given an option to share the password with you. If I click yes, your UI will not show the password, but connect directly to the wifi. Pretty solid UX. https://support.apple.com/en-us/HT209368 https://support.apple.com/en-us/HT209368
  - jtbayly 6y ago
    It's like magic. You're about to ask somebody if they know the password, and then all of the sudden your phone fills it in for you and says that your friend shared it with you. Every time I use it I love it.
    - afavour 6y ago
      It's like magic when it works. But in my experience a bunch of times it doesn't work and it's really not clear why. A shame because as you say, when it works, it works great.
      - kfriede 6y ago
        Sounds like most of my experiences with Airdrop (though recently it does seem to be working better)
        gtf21 6y ago
        I used to have this with airdrop all the time, and handoff too. So much potential but never really worked well. When it works it feels magical, but most of the time I just ended up being frustrated and copying things up and down via dropbox.
      - wojciii 6y ago
        Send the HCI logs from both devices to apple and let them scratch their heads as to why their protocol doesn't work all the time.
    - gingericha 6y ago
      To piggyback off afavour's comment: I do wish they would provide a button to prompt the sharing if for some, unexplainable (yet not uncommon) reason it doesn't automatically trigger the sharing tray
  - remram 6y ago
    Interesting. Does it actually delegate the authentication to your phone, or does it send the password? My Android allows to share the password with a QR code, which is certainly not as ergonomic... in fact it's slower than spelling it out, even to 1 friend.
    - ocdtrekkie 6y ago
      It sends the password, not really reasonable for it to only be able to authenticate one Wi-Fi device if another Wi-Fi device is still present. Wi-Fi passwords aren't really that secure a thing these days, anyways. If you need your Wi-Fi to be secure, you need to be doing RADIUS authentication or similar. It's just from a UI standpoint that it's very seamless. You don't have to see the password, you don't have to enter it anywhere, one device just shares the Wi-Fi password with another device nearby.
      - SEJeff 6y ago
        With an access point that supports really good beam forming.
    - arghwhat 6y ago
      WPA PSK unfortunately couples encryption and authentication, so users require the key at all times. Your key is too simple if it's easier to spell out. :)
    - dingaling 6y ago
      > My Android allows to share the password with a QR code Seems eminently sensible, no dependency on WiFi or Bluetooth stacks and works cross-platform. A QR also lets you force the recipient onto a guest SSID instead of your LAN
      - zaroth 6y ago
        I wonder if there’s a standardized URL to encode SSID and Password or if they just had to make one up. Presumably Apple doesn’t support this QR method? QR of course requires a screen and a camera, whereas Bluetooth can work on, for example, an Apple TV type device, or a smart speaker. EDIT: So then the trick is being able to generate the QR code easily and securely (without having to send your WiFi password to the cloud). Presumably free apps exist to do this.
  - amelius 6y ago
    Instead it should issue a ticket which allows one to use your WiFi for a limited time.
    - KMag 6y ago
      These days, even a very cheap ARM core has enough horsepower to run ChaCha20 w/ Poly1305 over every packet plus one Curve25519 multiplication per subscriber every 24 hours, plus generating and signing one Curve25519 short-term Diffie-Hellman key every hour. Using a shared symmetric ChaCha20 w/ Poly1305 key to encrypt and authenticate the client's sign-on Curve255 exchange, you'd get a variety of usage modes for free without adding any special cases to the access point's side of the protocol. The basic use case is that your device knows the password, so it listens for the periodic SSID announcement with the signed short-term DH public key. Your device then performs its side of the DH key agreement, and encrypts-and-MACs the public value with the password-derived key. The access point decrypts your public DH value, completes key agreement, and uses the agreed key to encrypt your short session ID, its expiry time, and a 256-bit ChaCha20/Poly1305 key[0] for the session, and send it back to your device. In the case of temporarily granting access to a guest, the guest's device would generate a public DH value and send it to you. You'd then encrypt-and-MAC that exchange message and send it back to your friend's device. The friend's device would then be able to forward the DH exchange to the access point and sign on once. They'd have a session ID and encryption key that's valid until expiry. In the case of a coffee shop granting temporary access to a paying customer, the phone could put its ephemeral public DH value in a QR code, and the cash register could scan the QR code, encrypt-and-MAC the public DH parameter, and directly send the value to the access point, at which point the customer's device could sniff and decrypt the sign-on message to learn its session ID and session key. Each device gets its own session ID and session key, so they can't eavesdrop on each other. If Curve22519 ends up getting broken, an attacker would still need to break ChaCha20 or learn the password in order to grab session keys. The client-side DH parameter still holds 252 bits of entropy (Curve25519's cofactor is 8, so the generator generates a 2*252 subgroup), and computing an Elliptic curve logarithm on this value still requires first decrypting the ChaCha20-encrypted sign-on message. You wouldn't get perfect forward secrecy, but you would get forward secrecy through the timed key rotation of both the short-term DH keys and rotation of any symmetric keys used to avoid storing any per-session state in the access point. [0] The session encryption key wouldn't simply be the DH-agreed key in order to allow the access point to avoid keeping per-session state and instead derive session keys from session IDs using periodically rotating symmetric encryption keys known only to it. The access point would need to guard against session IDs rolling over faster than they expired (and expiry would need to coincide with key rotation), but it's a simple check.
rektide 6y ago
TIL Apple has their own encoding format, opack. https://github.com/seemoo-lab/openwifipass/blob/main/OPACK.md https://github.com/seemoo-lab/openwifipass/blob/main/OPACK.m...
tomas789 6y ago
I’ll definitely implement it on a button press in by AppDaemon linked to the Home assistant.
- 1996 6y ago
  It's a very interesting proof of concept. Now if it could work on non apple devices (like when pressing the button on your router) I'd certainly code something with it too! Usecase: you are at your desk with a new laptop (or a friend), the router is in the other room and the password is long, and you can't find where you put the QR code the last time. On linux, it could get the active wifi network from iwconfig and the password currently used from either wpa agent, seahorse or others. It should present the password in a window, in case it contains an identifier.
  - 2Gkashmiri 6y ago
    at least on my kde neon you just right click on the connected wifi and press show QR code.
  - IggleSniggle 6y ago
    I send WiFi credentials and contact info to my smart watch as QR codes (as well as phone). Convenient medium for this use case, always present and on my person, invisible when not needed.
javageek 6y ago
That's what guest networks are for. I have a QR code next to the router for any guest coming to our house that wants to use our WiFi.
- jackson1442 6y ago
  QRs are significantly less useful for laptops, which makes it really nice to be able to enter the password/scan the code on my phone and just send it over to my macbook.
- pletsch 6y ago
  Does it automatically connect after scanning?
  - IggleSniggle 6y ago
    On Apple and Android, when you scan a WiFi QR, it pops up a notification that, if you tap on it, results in your phone automatically connecting to the network.
- rconti 6y ago
  .. so all we need to do is create guest networks on every wifi network, put all routers around the world in public view, and print QR codes to stick next to them. Perfect!
franga2000 6y ago
Isn't there a proper 802.whatever standard for "inviting" devices into the network? Android does it with QR codes, but Bluetooth can also be used. Is this that, or did Apple reinvent the wheel again?
- emteycz 6y ago
  Are you sure Android didn't reinvent the wheel (again)? I certainly remember iOS having the option far earlier than any Android.
  - franga2000 6y ago
    Yes, quite sure. They implemented an existing protocol called DPP (Device Provisioning Protocol), more commonly branded as "Wi-Fi Easy Connect", that is a part of the 802.11 standard and implemented by more than just Google. If Apple isn't using that, then it's them who are ignoring the standards and doing their own thing.
    - brorfred 6y ago
      It seems like DPP is part of WPA3, which came out in late 2018 and Apple’s version was first introduced in iOS 11, which was released 2017?
- nashashmi 6y ago
  Remember WPS? Apple never implemented that and then android removed it too. Ugh. On iPhone if you and a friend in iMessage are together and one can connect to a protected WiFi, the other can connect to. Automatically.
  - pmontra 6y ago
    What if the owner of the WiFi network wants you to connect but not your friends? Scenario: people come to my home, I give the password to a friend of mine that never visited me before or changed phone and asks me for the password. I don't know the other people and they don't ask for the password, but they get on the network anyway? Principle of most surprise and least security.
ogre_codes 6y ago
The beauty of Apple's solution is around ubiquity. There are piles of Apple devices with iOS versions that support this. It took me zero effort to set up and I can add my mom to my network in about 2 minutes. Even if I use Linux... chances are nobody coming over to my place is going to benefit from this. Not panning it, and maybe it'll work with Android eventually. But as it is I can't see bothering with this.
luma 6y ago
This could be really helpful in the embedded space on devices like the ESP32 which offer both the BTLE radio required to advertise the feature and the WiFi radio to make use of it.
- robterrell 6y ago
  Exactly my first thought too. Micropython's ubluetooth might be usable for this.
minhaz23 6y ago
create a guest network

232 points by jagged-chisel 6y ago

What does Apple's Wi-Fi Password Sharing do? Share the password between a user's device? With other users? Based on location, contacts?

t0mas88 6y ago
I think the main use-case is sharing the Wifi password from your iPhone to your Apple Watch or iPad. But it also works with people in your contacts if you are already connected to a network (let's say your home network) and a friend is trying to connect to that same network.
- djrogers 6y ago
  Those 2 use cases are completely separate, and the one that’s being discussed here is the second one. The first is covered by iCloud Keychain sync.
bberenberg 6y ago
You connect to wifi in my house (or anywhere where I am connected to a password protected netwrok). If we both have BT enabled and are in each others contact list, I am given an option to share the password with you. If I click yes, your UI will not show the password, but connect directly to the wifi. Pretty solid UX. https://support.apple.com/en-us/HT209368 https://support.apple.com/en-us/HT209368
- jtbayly 6y ago
  It's like magic. You're about to ask somebody if they know the password, and then all of the sudden your phone fills it in for you and says that your friend shared it with you. Every time I use it I love it.
  - afavour 6y ago
    It's like magic when it works. But in my experience a bunch of times it doesn't work and it's really not clear why. A shame because as you say, when it works, it works great.
    - kfriede 6y ago
      Sounds like most of my experiences with Airdrop (though recently it does seem to be working better)
      - gtf21 6y ago
        I used to have this with airdrop all the time, and handoff too. So much potential but never really worked well. When it works it feels magical, but most of the time I just ended up being frustrated and copying things up and down via dropbox.
    - wojciii 6y ago
      Send the HCI logs from both devices to apple and let them scratch their heads as to why their protocol doesn't work all the time.
  - gingericha 6y ago
    To piggyback off afavour's comment: I do wish they would provide a button to prompt the sharing if for some, unexplainable (yet not uncommon) reason it doesn't automatically trigger the sharing tray
- remram 6y ago
  Interesting. Does it actually delegate the authentication to your phone, or does it send the password? My Android allows to share the password with a QR code, which is certainly not as ergonomic... in fact it's slower than spelling it out, even to 1 friend.
  - ocdtrekkie 6y ago
    It sends the password, not really reasonable for it to only be able to authenticate one Wi-Fi device if another Wi-Fi device is still present. Wi-Fi passwords aren't really that secure a thing these days, anyways. If you need your Wi-Fi to be secure, you need to be doing RADIUS authentication or similar. It's just from a UI standpoint that it's very seamless. You don't have to see the password, you don't have to enter it anywhere, one device just shares the Wi-Fi password with another device nearby.
    - SEJeff 6y ago
      With an access point that supports really good beam forming.
  - arghwhat 6y ago
    WPA PSK unfortunately couples encryption and authentication, so users require the key at all times. Your key is too simple if it's easier to spell out. :)
  - dingaling 6y ago
    > My Android allows to share the password with a QR code Seems eminently sensible, no dependency on WiFi or Bluetooth stacks and works cross-platform. A QR also lets you force the recipient onto a guest SSID instead of your LAN
    - zaroth 6y ago
      I wonder if there’s a standardized URL to encode SSID and Password or if they just had to make one up. Presumably Apple doesn’t support this QR method? QR of course requires a screen and a camera, whereas Bluetooth can work on, for example, an Apple TV type device, or a smart speaker. EDIT: So then the trick is being able to generate the QR code easily and securely (without having to send your WiFi password to the cloud). Presumably free apps exist to do this.
- amelius 6y ago
  Instead it should issue a ticket which allows one to use your WiFi for a limited time.
  - KMag 6y ago
    These days, even a very cheap ARM core has enough horsepower to run ChaCha20 w/ Poly1305 over every packet plus one Curve25519 multiplication per subscriber every 24 hours, plus generating and signing one Curve25519 short-term Diffie-Hellman key every hour. Using a shared symmetric ChaCha20 w/ Poly1305 key to encrypt and authenticate the client's sign-on Curve255 exchange, you'd get a variety of usage modes for free without adding any special cases to the access point's side of the protocol. The basic use case is that your device knows the password, so it listens for the periodic SSID announcement with the signed short-term DH public key. Your device then performs its side of the DH key agreement, and encrypts-and-MACs the public value with the password-derived key. The access point decrypts your public DH value, completes key agreement, and uses the agreed key to encrypt your short session ID, its expiry time, and a 256-bit ChaCha20/Poly1305 key[0] for the session, and send it back to your device. In the case of temporarily granting access to a guest, the guest's device would generate a public DH value and send it to you. You'd then encrypt-and-MAC that exchange message and send it back to your friend's device. The friend's device would then be able to forward the DH exchange to the access point and sign on once. They'd have a session ID and encryption key that's valid until expiry. In the case of a coffee shop granting temporary access to a paying customer, the phone could put its ephemeral public DH value in a QR code, and the cash register could scan the QR code, encrypt-and-MAC the public DH parameter, and directly send the value to the access point, at which point the customer's device could sniff and decrypt the sign-on message to learn its session ID and session key. Each device gets its own session ID and session key, so they can't eavesdrop on each other. If Curve22519 ends up getting broken, an attacker would still need to break ChaCha20 or learn the password in order to grab session keys. The client-side DH parameter still holds 252 bits of entropy (Curve25519's cofactor is 8, so the generator generates a 2*252 subgroup), and computing an Elliptic curve logarithm on this value still requires first decrypting the ChaCha20-encrypted sign-on message. You wouldn't get perfect forward secrecy, but you would get forward secrecy through the timed key rotation of both the short-term DH keys and rotation of any symmetric keys used to avoid storing any per-session state in the access point. [0] The session encryption key wouldn't simply be the DH-agreed key in order to allow the access point to avoid keeping per-session state and instead derive session keys from session IDs using periodically rotating symmetric encryption keys known only to it. The access point would need to guard against session IDs rolling over faster than they expired (and expiry would need to coincide with key rotation), but it's a simple check.

rektide 6y ago

TIL Apple has their own encoding format, opack. https://github.com/seemoo-lab/openwifipass/blob/main/OPACK.md https://github.com/seemoo-lab/openwifipass/blob/main/OPACK.m...

tomas789 6y ago

I’ll definitely implement it on a button press in by AppDaemon linked to the Home assistant.

1996 6y ago
It's a very interesting proof of concept. Now if it could work on non apple devices (like when pressing the button on your router) I'd certainly code something with it too! Usecase: you are at your desk with a new laptop (or a friend), the router is in the other room and the password is long, and you can't find where you put the QR code the last time. On linux, it could get the active wifi network from iwconfig and the password currently used from either wpa agent, seahorse or others. It should present the password in a window, in case it contains an identifier.
- 2Gkashmiri 6y ago
  at least on my kde neon you just right click on the connected wifi and press show QR code.
- IggleSniggle 6y ago
  I send WiFi credentials and contact info to my smart watch as QR codes (as well as phone). Convenient medium for this use case, always present and on my person, invisible when not needed.

javageek 6y ago

That's what guest networks are for. I have a QR code next to the router for any guest coming to our house that wants to use our WiFi.

jackson1442 6y ago
QRs are significantly less useful for laptops, which makes it really nice to be able to enter the password/scan the code on my phone and just send it over to my macbook.
pletsch 6y ago
Does it automatically connect after scanning?
- IggleSniggle 6y ago
  On Apple and Android, when you scan a WiFi QR, it pops up a notification that, if you tap on it, results in your phone automatically connecting to the network.
rconti 6y ago
.. so all we need to do is create guest networks on every wifi network, put all routers around the world in public view, and print QR codes to stick next to them. Perfect!

franga2000 6y ago

Isn't there a proper 802.whatever standard for "inviting" devices into the network? Android does it with QR codes, but Bluetooth can also be used. Is this that, or did Apple reinvent the wheel again?

emteycz 6y ago
Are you sure Android didn't reinvent the wheel (again)? I certainly remember iOS having the option far earlier than any Android.
- franga2000 6y ago
  Yes, quite sure. They implemented an existing protocol called DPP (Device Provisioning Protocol), more commonly branded as "Wi-Fi Easy Connect", that is a part of the 802.11 standard and implemented by more than just Google. If Apple isn't using that, then it's them who are ignoring the standards and doing their own thing.
  - brorfred 6y ago
    It seems like DPP is part of WPA3, which came out in late 2018 and Apple’s version was first introduced in iOS 11, which was released 2017?
nashashmi 6y ago
Remember WPS? Apple never implemented that and then android removed it too. Ugh. On iPhone if you and a friend in iMessage are together and one can connect to a protected WiFi, the other can connect to. Automatically.
- pmontra 6y ago
  What if the owner of the WiFi network wants you to connect but not your friends? Scenario: people come to my home, I give the password to a friend of mine that never visited me before or changed phone and asks me for the password. I don't know the other people and they don't ask for the password, but they get on the network anyway? Principle of most surprise and least security.

ogre_codes 6y ago

The beauty of Apple's solution is around ubiquity. There are piles of Apple devices with iOS versions that support this. It took me zero effort to set up and I can add my mom to my network in about 2 minutes. Even if I use Linux... chances are nobody coming over to my place is going to benefit from this. Not panning it, and maybe it'll work with Android eventually. But as it is I can't see bothering with this.

luma 6y ago

This could be really helpful in the embedded space on devices like the ESP32 which offer both the BTLE radio required to advertise the feature and the WiFi radio to make use of it.

robterrell 6y ago
Exactly my first thought too. Micropython's ubluetooth might be usable for this.

minhaz23 6y ago

create a guest network