Discovering "Contacts Only" devices

[milke]

Not really an issue, but just a question. Possibly a dumb one, as I'm rather inexperienced when it comes to cryptography, certificates and signing keys. Forgive me for that in advance. I should also mention I'm playing with OpenDrop on macOS, running on top or native AWDL, no OWL involved, although I don't think it makes any difference for this particular question.

If I read correctly, what I can understand from this paper (section 3.3) and OpenDrop source file util.py, (line 94), in order to discover and send files to a device in Contacts Only mode, two certificates are needed. The first one is a device-specific Apple-signed certificate, with subject name something like com.apple.idms.appleid.prd.uuid, where uuid part is an Apple ID account UUID. The certificate is usually placed into user's login Keychain when logging into the device with its Apple ID. The whole purpose of this certificate is to get that UUID (and put it into the record data) and if one can figure out some other way of doing it (e.g. using Apple's private Sharing framework), that certificate is not needed at all.

The second certificate is used to sign binary plist data of created record data. It is said that "to be accepted by Apple clients, we would need the Apple-owned private key of the signing certificate", and of course we don't have it. When my Apple AirDrop devices in Contacts Only mode are discovered by my Mac, I assume the record data containing my Apple ID UUID and hashed contacts is somehow signed on the Mac and send to those devices when trying to establish an authenticated connection. So, if there are no Apple-owned private keys on my Mac, I wonder how that record data gets signed when the Mac initiates authenticated connection to other AirDrop device.

Once again, I apologise for potentially dumb question for the reasons I explained in the first paragraph and thanks for clarification.

[schmittner]

You are correct that there are two certificates involved:

1. the TLS certificate which is signed by Apple but the user device has the private key
2. the validation record certificate (with the contact ID hashes) which is also signed by Apple but the user device does not have the private key Both certificates contain the same UUID. With (1), the device opens a TLS tunnel which is used to transfer (2). If both UUIDs match, the other peer can be sure that the contact identifiers in (2) are correct.

We could (and can) extract the required data (1) and (2) from the keychain of an existing Mac (requires disabling the system integrity protection), i.e., and use it together with OpenDrop to authenticate to other devices in contacts-only mode. Obviously that only works for our contacts and we cannot create arbitrary versions of (1) and (2) exactly because we don‘t have Apple private signing keys.

Hope this answers your question.

[milke]

Thanks a lot for the precise answer. You actually clarified to me that in case of (2) it's not a certificate (and accompanying private key) that one needs to extract and then create record data and sign it with the certificate, actually that certificate contains the record data already created and signed, right?

My use case would be rather simple; a very simple Mac application, which would be able to detect and send files to AirDrop devices in Everyone mode by default and if a user wants it to work with devices in Contacts Only mode, he/she would need to disable SIP, run the application again and click certain button. That would extract needed data and save it to some application specific location, or even better for increased security, it would save that data as a new keychain entry in user's login keychain. After the extraction, the user could enable SIP back and the application would continue using data saved in the new accessible keychain entry. I understand the procedure would work only for that particular logged in user and every other user would have to repeat the same procedure.

Your answer yield just one more question; you said all required data can be extracted from the keychain (with SIP disabled). From a quick look in the Keychain Access application, I can't figure out on first sight what those required certificates (1) and (2) could be. Before I start digging on my own, I'd be thankful if you can provide some pointers and hints.

Thanks again and big thanks too to you and the whole team for this incredible job of reverse-engineering ADWL and AirDrop 👍.

[schmittner]

What you plan to do is possible.

Regarding the keychain items: we are currently working on a more sophisticated version of OpenDrop that will also do proper certificate verification. When that is out, we'll also release the code to extract the relevant keychain items. However, I can't give you a precise timeline right now...

[milke]

Okay, thanks. That's fair. As much as I'd like to have any info now, I respect and understand your stance on the issue.

[milke]

Hi, pinging again… I know I've got quite clear answer, but I'd like to know if there's any chance I get any hints on how to achieve the above (getting relevant keychain items) before the new version of OpenDrop is released? I tried hard myself, but no luck, mu reverse engineering skills are rather limited.

[schmittner]

@milke there you go :)