shared AirTags incompatible (only key provided is `peerTrustSharedSecret`)

[robertsmd]

The decrypted plist for an AirTag that has been shared with me is the following. This is incompatible with the current library due to not having a private key. Yes, I've tried using the peerTrustSharedSecret as the private key, it doesn't work as-is.

Seems like a good way to implement this would be to examine the traffic to Apple servers when examining the location of a shared AirTag via the FindMy application. It may use a different endpoint for an intermediary step between peerTrustSharedSecret and privateKey.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>cloudKitMetadata</key>
	<data>
	#Base64 blob here#
	</data>
	<key>communicationsIdentifier</key>
	<dict>
		<key>ids</key>
		<dict>
			<key>correlationIdentifier</key>
			<string>#uuid (unknown what it is) here#</string>
			<key>destination</key>
			<dict>
				<key>destination</key>
				<string>mailto:#Owner email here#</string>
				<key>type</key>
				<integer>0</integer>
			</dict>
		</dict>
	</dict>
	<key>displayIdentifier</key>
	<string>#Owner email here#</string>
	<key>identifier</key>
	<string>#baUUID here#</string>
	<key>peerTrustSharedSecret</key>
	<dict>
		<key>key</key>
		<dict>
			<key>data</key>
			<data>
			#INSERT KEY HERE#
			</data>
		</dict>
	</dict>
	<key>type</key>
	<integer>1</integer>
</dict>
</plist>

[malmeloo]

Which privateKey do you mean exactly? Using a KeyPair directly will definitely not work, as that would require a software update to all AirTags and kind of defeats its anti tracking measures.

What is the length of the peerTrustSharedSecret value? I'm really hoping it's just a concatenation of existing values... I do doubt that though, as that would make access revocation impossible.

I'm actually really curious how they implemented this sharing mechanism in the first place. Offloading the shared secrets to the users' device would be a security issue due to that revocation problem, but fetching them from Apple's servers would mean that Apple themselves has access to the AirTag's locations. Unless Apple only has a part of all the generated keys for a given time range, and those keys are then combined using that peerTrustSharedSecret on-device. Definitely interesting to look into.

[robertsmd]

length of peerTrustSharedSecret is 44 base64'ed or 32 raw. This is the same as the sharedSecret and secondarySharedSecret.

[malmeloo]

Unfortunate, I guess we'll need some traffic dumps then indeed.

[robertsmd]

I did a little testing. It looks like the owner is the intermediary. I tried airplane mode'ing the owner devices for a bit. The shared person was able to see AirTags that were shared and nearby (within BTLE range), but AirTags that were out of direct range did not update while the owner devices were offline. When owner devices came back within range, the latest location was updated. I'm presuming what happened is the owner device went online, fetched the most recent observation from the apple database, then was able to relay it to the shared person's device.

[robertsmd]

seemoo-lab/openhaystack#243

[parawanderer]

I did a little testing. It looks like the owner is the intermediary. I tried airplane mode'ing the owner devices for a bit. The shared person was able to see AirTags that were shared and nearby (within BTLE range), but AirTags that were out of direct range did not update while the owner devices were offline. When owner devices came back within range, the latest location was updated. I'm presuming what happened is the owner device went online, fetched the most recent observation from the apple database, then was able to relay it to the shared person's device.

Hi, I came across this thread since I finally came around to doing the shared AirTag setup with the library.

So I think there's actually a discrepancy in the FindMy UIs versus what is available from Apple's crowdsourced location reports, generally.

The Apple servers seem to have more recent locations actually available than what is shown in the FindMy app on both MacOS (tested version: 14.7.4) and on an iPad (tested OS version: 18.3.2).

In my case, I have:

• An official Apple Airtag, firmware version 2.0.72, which was registered a month or so ago via an iPad (OS version 18.3.2)
• This AirTag has been disconnected from its parent device for a while now
• (This is probably irrelevant but while it was disconnected, I shared it with some other Apple user)
• Currently my MacOS 14.7.4 FindMy app says "No location found" regarding this device (it may or may not be related that I logged out and logged back in to different accounts on this computer, which might have made it lose the location history?)
• Currently my iPad OS 18.3.2 FindMy app says the last update was "4 days ago"
• The FindMy.py library is able to fetch accurate reports for all those last 4 days

I wonder if this is some anti-stalking measure that they decided to only implement in the front-end 😄

[parawanderer]

Hi @malmeloo , I'm curious, how would you go about investigating the traffic from the FindMy MacOS app?

I'm not very involved in reverse engineering/security research, but I was curious about investigating this particular setup on my VM. I'm familiar with e.g. WireShark and I know there's various setups you can use to decrypt your own SSL/TLS traffic that comes from Web Browsers (I recall there's options to set some environment variable which makes "nice" browsers dump the certificates to a file that you can import in WireShark?). I can furthermore see the traffic I get from the FindMy app is seemingly just TLS 1.2.

So I'm wondering what would the equivalent setup be to analyse your own traffic coming from the FindMy app in a MacOS VM? I imagine the actual data will be in some binary format based on protobuffers or something after the decryption, but that's whatever.

[malmeloo]

I honestly haven't done any reverse engineering efforts on macos before, so I'm not entirely sure how that would work. You can install your own SSL root certificate, but I doubt the FindMy app (or whatever background process) would use that. In which case you'd have to bypass SSL pinning somehow.

[parawanderer]

I honestly haven't done any reverse engineering efforts on macos before, so I'm not entirely sure how that would work. You can install your own SSL root certificate, but I doubt the FindMy app (or whatever background process) would use that. In which case you'd have to bypass SSL pinning somehow.

@malmeloo Oh damnit lol. I typed this question into chatgpt and it mentioned bypassing the SSL pinning by messing with the binary and messing with a bunch of tools manually and it all seemed too annoying and timewastey to bother with. I was hoping somebody already figured it out and would save me that time 😅

Well no worries. I think for now I will abandon that plan then because I have some higher priority things to do but might return to this at some point. Ty!

[glorantq]

Hello! I've stumbled upon this issue while looking into shared tags myself, and found that there's much more that goes into this sharing business.

When you share a tag, a "sharing circle" gets created with everyone in it. This sharing circle allows people who are shared the same tag to know about eachother. For every member, you get their name, a correlation identifier, and a peerTrustSharedSecret (this secret is only filled in in the owner's plist; for every other member it's 0, so you just see names). There's another plist file, that describes the circle itself: has an identifier, a list of members (ids from before), and the tag owner's id.

With the ID of the sharing circle, there are a number of secrets we can access:

• circleSharingSecret, 32 bytes of random data
• circleWildRootKey, 32 bytes of random data
• nearOwnerLocationKey, plist, looks like it has a key under key.data inside it
• joinToken, plist, has the circle owner's ID and a field called "privateKey"

The setup seems logical, question is, how are all these keys correlated to eachother. I would assume that the nearOwnerLocationKey would be used to decrypt special reports published by the owner's device when the tag is near, but one of the keys has to be good for the regular, offline reports as well.

[glorantq]

Guessing here, but from first impression I think all members with whom the owner shared the tag derive a new keypair, probably involving the crcleWildRootKey, the circleSharingSecret and the shared secret with the owner. This would make sense, as there would be a "new" "device" for each member you have shared with, so they can't access past reports, and updates can be revoked by just not updating this fake "device".

As for the nearOwnerLocationKey, I don't immediately see why it would be different. Maybe if my previous assumption holds with the new fake "device", near owner reports are published but encrypted with this key, instead of the private key derived for that? I don't immediately see the benefit of having 2 separate keys for regular and nearby reports, but it probably exists for good reason.

[malmeloo]

Great work! It appears that the system is a lot more convoluted than I first suspected. It would make a lot of sense if the owner device is re-publishing location reports encrypted using a different (rotating?) key for each person through the existing OF network. Apple is able to reuse a lot of their existing infrastructure that way, while still allowing easy access revocation as you mentioned. I also highly doubt Apple did any major architectural restructuring just for this feature.

If that's true, then one of those fields is probably the key using which reports are being encrypted. It could also be a combination of those fields that is used to generate a rotating key, like AirTags do. Although I don't really think that would provide any privacy benefits? Unless obfuscation counts, I guess.

I think the nearOwnerLocationKey might be one of the input values to the AirTag's public key generators. Depending on which values you plug in, the algorithm will spit out either public or private keys. Sharing the input values to the public key generator would grant other parties in the circle irrevocable access to the tag's public key stream, which can be used to detect whether a tag is nearby, but is useless when it comes to actually decrypting the location reports.

Would you be able to capture some network dumps to see what's going on under the hood? There is a Frida script floating around in a github gist that you can use to disable ssl pinning (not currently near my laptop so that's all the deets I've got right now, sorry). It's quite late for me already, but I can help you with it in the morning.