What an attacker gets from Apple devices if they sniff Bluetooth traffic

Agreed. It is weird that they just hash the phone number and don't salt it with something else. Even just appleid+phonenumber would be huge and prevent pre-attacks.

And for the phone number part, “If Bluetooth is ON on your Apple device AND you’re trying to Airdrop something (which you’d expect to send some identifying information) or connect to a new WiFi network (same)...”

To be fair I wouldn’t necessarily expect those actions to send out a hash of my phone number, but the threat indicated by the title is definitely overblown.

A part of the problem is that bluetooth is almost always ON on iPhones. The way one typically toggles it from the control center only disables bluetooth for a short period of time (24 hours), after that, it turns on again. One has to go into settings to actually disable bluetooth.

I believe that this information leak occurs BECAUSE AirDrop is only enabled for Contacts by default - you disclose your own hashed phone number when you open the Share dialog in order to allow nearby phones to decide whether you're on their Contacts list.

But Airdrop for contacts only is basically broken-especially for sharing between your own devices that are supposed to be on the same apple id-so you need to set it to ‘everyone’ for it to work all the time

https://en.wikipedia.org/wiki/Socialist_millionaires ?

Send nonce+hash(phonenumber+nonce)? Then recipient could just iterate over contacts and check if they get same hash for anyone. Expensive but works?

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?

From the article:

> 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.

This isn't my specialty, but I'm interested in cryptography. Here goes:

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))))

Alice's device computes the hash of the nonces, then iterates her contacts to find the one whose public key verifies the signature.

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.

On some morning flights I'd bet that close to half of the passengers are using some type of wireless noise cancelling headphones, and I have yet to notice any problems. So the bandwidth or noise doesn't seem to be an issue.

The edge case would be a someone using these techniques on, say, an attractive woman three seats down on the train.

In addition, one (hypothetically) could use iOS state awareness in conjunction with other attack vectors to gain access: i.e., we have an attack vector to gain remote access, but it only works if the target device is unlocked.

First off, "someone can lift your phone number via you merely having Bluetooth running" is entirely not true of this information leak.

The scope of this issue is that an unsalted SHA256 of your phone number is broadcast when you open the Share dialog with AirDrop and Bluetooth active. Your phone number is broadcast to determine whether the sending device is in the receiving device's contacts list.

The feature that causes this information leak (AirDrop) has no equivalent on stock Android, but hundreds of horrifyingly insecure apps exist to replicate it.

Google are introducing a similar feature (Fast Share) soon and we will see how it fares security wise.

This is an interesting cryptography question: how do you allow two mutually untrusted client devices to determine that they share a common secret, without disclosing the secret? And for bonus points, how do you allow this to happen without two-way communication?

Tangentially, on Android every app you have run at least once can know your phone number through standard APIs. On iOS, as far as I know and as far as I have observed, there is no API for that — apps have to ask the user what the devices' phone number is and trust that input. So Apple revealing phone numbers (through a rainbow table of hashes attack) in this AirDrop sharing scenario isn't congruent with its approach of not revealing phone numbers in other cases.

I didn’t flag but it’s obvious why: the title and introduction paragraph is comically misleading. Without the hyperbole it would be an interesting discovery, with the hyperbole it’s obnoxious fear mongering.

> Any idea why this is flagged?

In my experience, anti-Apple sentiment tends to get either downvoted/flagged to oblivion or upvoted through the stratosphere. I suspect it's due to Apple being a particularly polarising firm: those who like it, love it, while those who dislike it, loathe it.

It got flagged for the title I think: https://news.ycombinator.com/item?id=20529383

Few hours later after flagging an admin has changed the title to the current one and un-flagged it. I just copy-pasted the title from the original one in the submisison without thinking much about it. In retrospect, the new title is much better.

Also as another commenter hinted, Apple has some very loyal fans.

The legal frameworks surrounding privacy all revolve heavily around "reasonable expectations of privacy". I can't be upset if someone learns salacious information from the street through an open window; but if I close the blinds and someone intentionally peeks through a crack, they are violating my expectation of privacy and potentially breaking a law, even though I failed to secure that privacy properly by covering every square inch of the window.

In some cases, it can be possible to use E2E encryption to create a secret that is functionally impossible to discover. But even in cases where digital security is flawed, vulnerable, or outsourced to a third party, it's still valuable to us from a legal standpoint to maintain social expectations of privacy.