Would you like an update to your SRP document (for server details)

[fduncanh]

I finally got server SRP working on the UxPlay AirPlay server (see https://github.com/FDH2/UxPlay/tree/pair-pin2 )

Your SRP doc is very useful, but is missing some details crucial to the server (as opposed to client) implementation that I discovered.

UxPlay already had a full server implementation of "10.2 RTSP session authentication", so only the SRP needed to be added to provide pair-pin-setup (it already did pair-setup without pin, which we recently switched off, as someone discovered that things worked fine without pairing, which eliminated a 5sec connection delay).

The 10.1 SRP step 3 (AES CRM 128 encrypted epk exchange has a crucial server detail that I discovered luckily (I dont believe there is a previous open source server implementation of apple SRP) which is a second iv[15]++ nonce after decrypting the client epk, before encrypting the server epk in the server response.

libraop client does not check the server epk, but true Apple clients do, and reject the server unless the iv was updated again before encrypting the server epk.

If you are interested, I could do a PR to update your doc with server details. Do you have a .md version that produces the html ,or would you accept hand-edited HTML?

• one issue I don't understand is what happens after the pairing is finalized to switch to fully-encrypted communication?
  UxPlay decrypts audio and video streams, but I thought full AirPlay2 encrypted all communications after pairing? Perhaps this is only with HomeKit authentication?

[philippe44]

Yes, a PR with an updated doc would be very welcome!

[fduncanh]

Hi @philippe44

I've been working on updating your doc with various clarifications etc.
I'll post a PR soon.

There are two issues I want to raise with you.

1. There is no reason that that the ED25519 public key <a_pub> should be built using the SRP6 ephemeral secret <a> as its raw private key. They are logically unconnected. Either build one with a differerent random 32 byte sequence,
   or better still use OpenSSL to generate a key pair. For example Apple clients have a persistent public key that survives reboots.

2. In your step 2 AES item 5, you say

• Encrypt <atv_data>, discard result

• Encrypt <signed>

While this works, I note that <atv_data> is just the server's version of <signature>, and I expect a true Apple client does examine it. If I understand correctly, AES CTR is symmetric, and more logically the pattern after receiving a message is to decrypt it, which should also advance the counter.

• could you check that replacing encryption of <atv_data> by decryption of it does not break your libraop?

I'm sure I could do this test, but it would take me a lot longer than you to do it.

• Maybe also test that using a different 32 byte sequence instead of <a> to generate <a_pub> does not break libraop.
  Since <a> is meant to be a SRP6 ephemeral, it should in principle be discarded at the end of pair-setup-pin, not used in pair-verify. The ED25519 public key is definitely not an ephemeral.

I looked to see what pair_ap does: <a> (as opposed to <A>) never gets converted from a BIGNUM to bytes, so is definitely not used to generate <a_pub> there.