Attack of the Week: Airdrop Tracing
blog.cryptographyengineering.com
blog.cryptographyengineering.com
However, also as far as I know...although VPNs are banned in China, there are ways to get them. I'd wonder how much do dissidents use Airdrop in this manner if they can access the global Internet anonymously. Given mass surveillance in China, I'm sure the Chinese government can track "oh this airdrop sender appears every time this person is in this station".
I also hope that Apple adopts an open source protocol for AirDrop not just for cross platform compatibility, but auditable security. Android has its own "Nearby Share". If Apple doesn't want to get in trouble for "fixing" this, they can easily adopt a cross platform compatible protocol that just happens to also fix this.
I don't know anything about the AirDrop or NearbyShare protocols, but I wonder if they can be implemented in such a device?
All the recently announced dedicated AI devices make me think people might be into it.
https://en.m.wikipedia.org/wiki/Operation_RAFTER
Having said that there isn’t really anything special about this particular technique of using numbers stations. It’s just a part of the same trick to pass along information via an open channel without having to give away what the message is about or who the intended audience is supposed to be.
Taking out an ad in the classifieds section of a newspaper is ultimately the same trick just with a much lower bandwidth to transmit anything useful beyond a simple signal.
One (definitely not insurmountable) problem that would exist in such a federated and open system is credential authentication:
Currently, Apple signs your email address and phone number (hash) so that you can't impersonate somebody's trusted contacts and send unwanted material to them without their consent, which has been a problem for Apple in the past. That's supposedly also why they have removed the "allow all AirDrop senders" option in favor of one that times out after 10 minutes.
There would either have to be a federated alternative to that, or the open source system would have to drop sender authentication; then you could only receive AirDrops while your device is in "allow all senders" mode.
The reason there's anything in the airdrop protocol that can be converted to a person is to allow your device to say who is sending it if you know their identity already, and/or to filter the messages if you don't.
The whole point of this activity was that people did not care, nor want to care, about who was sending payloads. In such an environment the solution is no identity at all, not federation of identity.
If you do try to do this simply because of "federation", all china does it use the same federation system to get the user information (because the whole point here is china was monitoring local bluetooth info, so some nebulous application of federation dust doesn't magically resolve anything).
The problem here is that people were using a system is not anonymous by design (there is a deterministic relationship between the underlying account and the hash by published design), and that relationship is necessary for basic functionality. A hindsight being 50/50 step could have been to use a password hashing function, but airdrop has existed long enough at this point for me to assume that the iterative systems would have relatively low iteration counts, and mobile hardware probably can't afford the resources to make every airdrop also perform memory bounding steps.
I'm not saying that federation solves the anonymity problem, I'm just saying that the current implementation includes Apple as a trust anchor for email address and phone number verification and issuance of corresponding certificates. My point is that in order to enable an open cross-platform solution, there would have to be some alternative mechanism to that.
What they could add is a sender-side option that makes sending completely anonymously. This would be possible without any change on the receiver side, but would require recipients to enable "allow all senders" mode.
In most cases this could also be resolved at first contact in meatspace, directly between the devices when establishing contact via the typical ways users share contact information - QR code or some form of short range networking, or even with an SMS challenge.
That really doesn't sound that easy in a federated protocol.
Especially from what they have been learning about generating viral from tiktok (the ADHD Dopamine Addicts in the growing adolescent brain is a gold mine)....
But one interesting thing I noticed on tiktok and reddit r/artisanvideos and others for example - is these agrarian-crafty-chipster videos.
Like the soft music, the beautiful landscapes, the cute dog in the background and all the nice, clean village-esque looking surrounding as some master craftsman makes bamboo mats, or tofu, or paper etc...
They look highly polished PR videos that one might see at an amusement park showing the "simple but accomplished life in china - look how elegantly crafty these simple folk are"
--
However - that doesn't mean they aren't making incredibly authoritarian tools disguised as benefits for society. and AI will engulf their tool set and accelerate. Just make sure to leave some bread, circuses and sex to distract the frogs from the temp in the cauldron.
Also you can get roaming SIM cards or even eSIMs, which connect to APNs overseas.
You can also get Alibaba Cloud private networking connection between a region inside of China and a region outside. They use private lines so there's no GFW involved. My understanding is that you need an international real name verified account to do this, but after that you basically have an uncensored line that's also much more stable than connections that have to go through the GFW. I know of a US company that uses this to connect their Chinese workers to their central office, and again it's fully legal once you get an ICP license.
Thank god that only the Chinese do it. Imagine what the reaction will be if someone finds out that the US or the Canadian or the UK government does it. /s
There was a user who pitched the idea of an airdrop like thing to Signal awhile back, specifically stating that it could be used for organization, but it didn't seem to get much traction and looks like they got in a little scuffle with the mods. Sounds like it would be a useful thing given the other security around Signal and the fact that it is cross platform.
Apple knew AirDrop users could be identified and tracked as early as 2019 - https://news.ycombinator.com/item?id=38971811 - Jan 2024 (13 comments)
China Says It Cracked Apple AirDrop to Identify Message Sources - https://news.ycombinator.com/item?id=38925681 - Jan 2024 (21 comments)
Apple already acted on this, didn’t they? AirDrop now defaults to off and you can only switch it on for ten minutes at a time – you can’t forget to switch it off again. When Apple implemented this change, I remember that they were criticised because people said they were doing what China wanted by cracking down on P2P communication. Now it’s the opposite situation but the same criticism.
I assume that it still broadcasts your hashes even in the contacts-only mode, so you'd need to turn receiving off to stop that. Or go a step further and disable Bluetooth entirely* when you don't need it.
* If you disable Bluetooth in the Control Center pulldown it won't actually disable Bluetooth or beacons. It just won't connect to devices. You need to go into Settings to actually disable Bluetooth.
Even before the discovery phase (which is where this issue sits), the two devices apparently create a TLS tunnel with both client and server certificates, signed by Apple and containing UUIDs linked to the device and Apple ID [0].
I have no idea if/where/how these certs are used elsewhere, but this seems like another avenue of identification and tracking even if it doesn't directly expose the phone number or email address. I'm pondering early IMSI catchers didn't expose the MSISDN, but enough listeners in various places seeing the same IMSI sure helped for correlation. Does anyone know of any writeups on Apple's internal (device) CA infrastructure?
[0] Section 2.4: https://www.usenix.org/system/files/sec21-heinrich.pdf
From the abstract
>We propose a novel optimized PSI-based protocol called PrivateDrop that addresses the specific challenges of offline resource-constrained operation and integrates seamlessly into the current AirDrop protocol stack
Is section 2.4 how it works today, or what they're proposing for the future?
That should make any attempts of pre-computed rainbow tables very expensive and only usable for a short time window.
Clearly, I'm of "a certain age" where I don't blindly trust anyone for anything. It's amazing how quickly the concept of trust has been tossed aside from tech
How is this any different than your phone accepting random MMS, imessages, or phone calls from any random phone number?
The first step is a device lookup with "Bonjour", which allows devices to ping each other an see who's who. Any network device since the 1980s pretty much does this by default unless you disable it. Remember Netbios?
The second step, is Airdrop requesting a device to accept a connection.
At that point, you see who is sending you the send request, and you can accept/deny. Airdrop is also disabled by default from unknown senders since a dude sent a dick pick on an airplane. Your Apple device will only accept connections from known contacts by default, and you can override that setting to allow connections from anyone.
You can disable this behaviour in Settings by blocking Airdrop.
From the article: > While AirDrop’s device-to-device communications channel is typically protected from third-party snooping by its own layer of security, that wouldn’t shield someone who may have been tricked into connecting with a stranger, perhaps by tapping on a deceptively named device in a list of contacts or by thoughtlessly accepting an unsolicited connection request. This step is required for the sender to be identified, according to security experts.
> At that point, you see who is sending you the send request, and you can accept/deny.
Revealing the identity hash must happen earlier than that, since the entire point of the "only contacts" feature is that you can't even see non-contacts on your AirDrop share sheet.
And since Apple (correctly, in my view) didn't want receiving devices to publicly broadcast their identities (or even worse the set of acceptable senders), it's on the sender to initially broadcast their identity to all devices within range.
The candidate devices (i.e. those that have the sender in their contacts) then respond and get populated in the share sheet target list.
What's potentially surprising is that this must happen even before selecting AirDrop as a share target, since (at least on my device) I can already see nearby AirDrop contacts in the "frequently contacted" part of the general share sheet...
The sender device broadcasts their identity, while the receiving devices will follow the Airdrop settings. When in contacts only and/or disabled, your device will not broadcast your personal identity in the clear.
Your device itself broadcasts its presence through various protocols.
This is a follow-up to the NetBIOS protocol that did the same (Windows shares is another example).
Operation triangulation https://securelist.com/operation-triangulation-the-last-hard... revealed the use of four different vulnerabilities, hidden code and undocumented features to take over Iphones. Its sophistication points to an APT. Apple did not deny helping the attacker TMK.
https://support.apple.com/guide/security/airdrop-security-se...
> Apple did not deny helping the attacker TMK.
I can imagine many non-malicious alternative explanations for Apple not commenting on that particular vulnerability. For example, doing that here opens the door to a future in which every non-denial is seen as implicit admission of collaboration.
It's also possible that Apple themselves was compromised: It's a large company, and other types of leaks do happen.
I'd focus much more on the things Apple very publicly does not do, such as in this case not using private set intersection for AirDrop.
The best vulnerability is the one you don't even have to defend, because it's just the absence of a more secure (but also more complicated) alternative. There are countless historical examples of that: Unencrypted instant messaging, non-end-to-end encrypted cloud storage etc.
Danger Will Robinson ö
“AirDrop uses iCloud services to help users authenticate. When a user signs in to iCloud, a 2048-bit RSA identity is stored on the device, and when the user turns on AirDrop, an AirDrop short identity hash is created based on the email addresses and phone numbers associated with the user’s Apple ID.”
https://support.apple.com/en-gb/guide/security/sec2261183f4/...
Same way it does with password manager
Not insurmountable, but it would probably be quite un-Apple-like.
I was also thinking you might be able to use asymmetric crypto for this, and encrypt the hash + a nonce using your private key, and anyone with your public key can decrypt it and check the hash against the contact list. But this means the potential receiver needs to decrypt with every public key it knows, which for large contact lists might be prohibitively expensive.
Someone has probably devised a more clever way, though.