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