Joonas' blog

How does Apple wifi password sharing work?

published

Recently while travelling, I experienced a strange phenomenon: my iPhone, which was as disconnected from internet as possible in order to save in roaming costs, somehow managed to ask my friend for the WiFi password that he had already managed to connect to. This got me intrigued, as it was not clear to me how is it possible for my device to interact with my friend’s device without internet when the only connection between us two is the fact that we’re on each other’s contact list.

I searched a bit and found the article Disrupting Continuity of Apple’s Wireless Ecosystem Security: New Tracking, DoS, and MitM Attacks on iOS and macOS Through Bluetooth Low Energy, AWDL, and Wi-Fi by Stute, Milan, et al., on which most of the technical details in this post are based on.

Technical requirements for password sharing to work

Password flowing through the air

These are the only technical requirements for password sharing to work:

  1. Both devices have Bluetooth enabled
  2. The giver device is unlocked and has the receiver (phone number or email address) in its contacts list
  3. The receiver is signed in with an Apple ID

Notably, the receiver does not need to have the giver in its contacts, and is not verified or authenticated in any way.

Blasting the world with “please help me” advertisements

Password heist operation starts with the device asking surrounding devices for help. This happens when you try to connect to a private WiFi hotspot and the password prompt opens.

Advertising my need for a password

Technically, this is implemented with BLE (Bluetooth Low Energy) advertisements. Advertisement packets in BLE use certain frequencies in the 2.4 GHz ISM band specifically meant for devices to talk with each other without having formed a Bluetooth pairing yet. Therefore, they work nicely for a shot-in-the-dark type message like the password request packet.

Apple’s password sharing message specifically includes four pieces of information:

  1. the first 3 bytes of the SHA-256 hash of the owner’s Apple ID
  2. the first 3 bytes of the SHA-256 hash of the owner’s email address
  3. the first 3 bytes of the SHA-256 hash of the owner’s phone number
  4. the first 3 bytes of the SHA-256 hash of the the SSID for which the receiver requests a password

These messages are received by other devices, which check their contact list for hash-prefix contacts matches and whether they know the password for a SSID that matches the given SSID hash. If they do, their device shows a popup asking whether they want to share their password. Pressing “yes, I do” will take you to the next step.

Pairing up and validating things

The next step is setting up encryption, making sure that the receiver is actually the contact and is allowed to receive the password, and then actually sending it with the encrypted channel.

Pairing up and sharing up

For details on step 1 and what the encryption looks like, refer to the original paper for a better explanation than I could give.

Step 2, or validating whether giver is communicating with a person who actually is who they claim to be, is an interesting process. When user signs into a device with an Apple ID, Apple issues a certificate containing a randomly generated UUID and an Apple-signed record data blob containing all contact identifiers registered with the user’s Apple ID in a hashed form. By using the Apple ID certificate to sign the public key used for encrypted communication, the giver can be sure that the device sending the data owns the hashed contact details included in the validation record data blob. Curiously, the same certificate and validation records are used in AirDrop protocol.

Once setting up encryption and authenticating the receiver have been done, the giver can send the SSID and the Wi-Fi key in an encrypted form. This wraps up the Apple password sharing process.

Acknowledgements

Please read or cite Disrupting Continuity of Apple’s Wireless Ecosystem Security: New Tracking, DoS, and MitM Attacks on iOS and macOS Through Bluetooth Low Energy, AWDL, and Wi-Fi by Stute, Milan, et al.. Information in this post is based on that and they are to be thanked for figuring these things out.

Additionally, A Billion Open Interfaces for Eve and Mallory: MitM, DoS, and Tracking Attacks on iOS and macOS Through Apple Wireless Direct Link by Stute, Milan, et al. was used for some specific knowledge about Apple ID certificates.