How do you allow two mutually untrusted client devices to determine that they share a common 9-digit number, without disclosing the secret? And for bonus points, how do you allow this to happen without two-way communication or access to a central authority?
When an iCloud user is created, a keypair is generated. The private key is stored in the user's keychain; the public key is pushed to iCloud's server and placed in a central directory. Public keys of all of the user's contacts are cached locally on the device.
When Alice opens her phone to share something via AirDrop, it polls available devices over BTLE. The polling message contains a nonce.
Bob's device responds with a message containing two values: a nonce of his own, and a hashed+signed payload:
(ecdsa_sign
(bobs_private_key,
(sha256_hash
(concat
alices_nonce,
bobs_nonce))))
This approach defeats a precomputed attack by including a nonce from both parties - a rainbow can't be generated for all transactions, only this one in particular. It does not expose Bob's identity, because all that is transferred is a (random) nonce and a signed message.
The main drawback I see here is that when adding a contact, you have to download their public key from iCloud before you can share with them - so two devices cannot use AirDrop if they are not online, if they have not been online since the contact was added. As a workaround, you could set a flag when unsynced contacts are present and show a dialog if an AirDrop poll is detected before syncing occurs. In that case, you could fall back to something more closely resembling the currently implemented protocol, which would at least limit the data leakage present today to an edge case that requires explicit approval by the user.
> your phone sends out SHA256 your phone number hash to all the devices around you every time you hit Share.
In theory, this should be enough to protect your number (although it's still a fingerprinting vector). The reason it's a problem isn't because other people can see the hash -- is because it's trivial to iterate over the list of possible phone numbers and figure out which one corresponds to each hash.
So... don't use 9 digit phone numbers. I'm sure I'm missing something, but this does not seem like a hard problem, at all.
Everyone using an Apple device has an Apple account. AirDrop is not compatible with Android; so this isn't a compatibility thing. I can't think of any reason why this needs to be a hash of a phone number instead of a randomized string that's attached to your account. Airdrop is fundamentally a way for you to share files across Apple devices -- so just give them new IDs.
Yes, this means that there's a tiny amount of coordination with Apple servers that would need to happen when you add a new contact or share with a brand new phone number you've never seen before, but is anyone on here seriously going to argue that's worse for privacy than essentially transmitting your phone number in the open every time you use AirDrop?
From later in the article:
> How does your friend know that the person requesting a password is you? Broadband BLE requests contain your data, namely, SHA256 hashes of your phone number, AppleID, and email.
There's a device with a screen, right in front of you, and the screen has to be visible for you to click the share button. Your friend also needs to be right next to you so that your phone's are close enough to connect over Bluetooth.
So pick one to two randomized dictionary words, display them on the screen, and just read that out loud to your friend as confirmation.
Is there something I'm misunderstanding about how these features work? The developers at Apple aren't dumb, so I'm assuming there's some good reason for needing to use a mobile number as a device ID for a proximity-based sharing service on a tightly-controlled device.
I would just have hashes of all the numbers of all your contacts on both phones and if your hash sent over matches you have a contact. No need to phone home.
That’s what came to mind to me when I read this article. iMessage already uses per-device public key encryption, it seems like per-device UUIDs hashed with the user<->user connection could be used to make the sniffed hashes non-reversible without knowing the UUIDs of the sharing phone and one of his contacts
OR send (handshake) message encrypted with recipients phone number (put through KDF). Anyone knowing the recipient probably could be able to get your phone number, but that seems like an improvement?
The second approach isn’t how AirDrop works as a product: when you open the Share dialog, you see a list of eligible recipients (either people with open permissions OR you in their contacts list). The recipient is the one doing the identity check, so their phone number isn’t known upfront.
One downside is that it may be make targeted attacks easier (if you can guess the approximate form of someone's email address, you can easily confirm it), but that doesn't seem like much of a leak if you can already guess sufficiently closely. Sending hash(nonce+AppleID+phone number) might be an option, but that feels more limiting.
I would suggest it's because phone number is (should be) device specific, while AppleID's can be shared across devices. But now that I think about it, does anyone know if AirDrop works with iDevices that don't have a SIM? Such as the iPod Touch?
Macs.