5 ms·

Here's the problem space - I'm interested in how HN would design AirDrop without this information leak: How do you allow two mutually untrusted client devices

by bri3d 7y ago

Here's the problem space - I'm interested in how HN would design AirDrop without this information leak: 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?

drewbug 7y ago
https://en.wikipedia.org/wiki/Socialist_millionaires https://en.wikipedia.org/wiki/Socialist_millionaires ?
zokier 7y ago
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?
- bri3d 7y ago
  The first approach protects against a global lookup table attack but doesn’t help with the root issue that a 10 digit phone number isn’t enough entropy and you could still brute force the number (depending on the hash algorithm) in seconds to hours. 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.
  - stordoff 7y ago
    I'm unfamiliar with AirDrop, but is there any reason it _has_ to work with phone numbers? Would sending nonce+hash(AppleID+nonce) work? I suspect an email address would have significantly more entropy than a phone number (36^6 * 4 ~= 10^10, so six alphanumerics plus four common email domains has about the same entropy (assuming random distribution-you could make better guesses)). 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.
    - phs318u 7y ago
      > is there any reason it _has_ to work with phone numbers? Would sending nonce+hash(AppleID+nonce) work? 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?
      - janfoeh 7y ago
        > does anyone know if AirDrop works with iDevices that don't have a SIM? Such as the iPod Touch? Macs.
        phs318u 7y ago
        Doh. Of course. Thanks.
    - Nemo157 7y ago
      The email address I use for Apple ID is not the same one my contacts would have.
danShumway 7y ago
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.
- giancarlostoro 7y ago
  > 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, 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.
LyndsySimon 7y ago
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.

by bri3d 7y ago

drewbug 7y ago

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

zokier 7y ago

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?

bri3d 7y ago
The first approach protects against a global lookup table attack but doesn’t help with the root issue that a 10 digit phone number isn’t enough entropy and you could still brute force the number (depending on the hash algorithm) in seconds to hours. 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.
- stordoff 7y ago
  I'm unfamiliar with AirDrop, but is there any reason it _has_ to work with phone numbers? Would sending nonce+hash(AppleID+nonce) work? I suspect an email address would have significantly more entropy than a phone number (36^6 * 4 ~= 10^10, so six alphanumerics plus four common email domains has about the same entropy (assuming random distribution-you could make better guesses)). 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.
  - phs318u 7y ago
    > is there any reason it _has_ to work with phone numbers? Would sending nonce+hash(AppleID+nonce) work? 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?
    - janfoeh 7y ago
      > does anyone know if AirDrop works with iDevices that don't have a SIM? Such as the iPod Touch? Macs.
      - phs318u 7y ago
        Doh. Of course. Thanks.
  - Nemo157 7y ago
    The email address I use for Apple ID is not the same one my contacts would have.

danShumway 7y ago

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.

giancarlostoro 7y ago
> 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, 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.

LyndsySimon 7y ago

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.