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!