10.1. RTSP pairing (required only + color="#09598a">10.1. RTSP pairing ("pin-pair-start" + "pair-setup-pin", required only once)
The This is needed
+ if the Apple TV (AirPlay server) is configured to require it (usual case) or if the client
+ requires it (often the case with corporately-owned MDM-managed clients).
+
+ The STEP
- 1 - CONFIRM PIN
- From
-that
- secret, create a public key <a_pub> using a Ed25519
+ The client will later need an ED25519
+ public-private keypair, generated from a "cryptographically-safe" 32-byte random number (the "raw
+ private key"). It is convenient (but NOT necessary) to also use the SRP6 "ephemeral" secret <a> as
+ the "raw private key" of the ED25519 keypair with public key <a_pub> used below.
+ Note that true Apple clients maintain a persistent public key that does not change if
+ the device is restarted.
+
The
- SRP6 public key corresponding to <a> (A = g ^<a> % N). client
@@ -453,11 +464,12 @@
The
pair-setup-pin POST request is used to display a PIN code on
the AppleTV.
Build
-a
+style="font-size: 12pt" size="3">
Build a
plist :256 bytes public key from AppleTV 256 bytes SRP6 public key from AppleTV salt STEP
- 2 - run SRPRP
Generate
locally
a 32 bytes random auth_secret (named <a>)
that will be used for all further verification with the AppleTV - DO
- NOT LOOSE IT.
+ NOT LOOSE IT.
+ To create the public key <a_pub> using <a> (or any other saved random 32 byte "raw"sequence),
+ use a Ed25519
( Edwards-curve Digital Signature Algorithm - EdDSA) – it
- will be needed later, but can be re-created at any time.
+ M1 proof calculated by the client.
Should be calculated by the SRP library
This
<M2>
can be checked against the <M2> calculated by SRP
@@ -480,12 +492,14 @@ proof <M2> 64 <M2> 20 The M2 proof calculated by the server
+ style="font-size: 9pt" size="2">The M2 proof calculated by the server
+ Should be calculated using a SRP6 library
- This
-last
- step is to confirm the secret auth_secret <a>.
- It requires a sha512 digest, and an AES encryption in GCM (Galois
- Counter Mode, which provides encryption and signature). This builds an
- encrypted message <epk> with its signed <authTag>.
+ After Step 2, both client and
+ server possess the SRP6 secret hash <K>, which enables them to exchange encrypted and
+ authenticated messages using AES encryption in CGM (Galois Counter Mode).
+
+ This last
+ step is to confirm the secret auth_secret <a>.
+ It requires a sha512 digest, and an AES encryption in GCM mode. This builds an
+ encrypted message <epk> with its signed <authTag>.
Build a
+ face="Segoe UI, sans-serif">Note that it appears that in this communication mode, the AES key
+ and IV used to encrypt and decrypt a message is updated (after decryption) by adding 0x01 to the last byte of the
+ AES IV before encrypting the reply message.
+ Build a
plist:
If
-the
- message is correct, the AppleTV should responds with a HTTP 200
- and a plist which means that the auth_secret <a>
- is now registered in the AppleTV as a valid secret
The
+ AppleTV (AirPlay server) then recreates
+ the AES key and IV used by the client, and uses them to decrypt <epk>,
+ with authentication by the <authTag>. Successful decryption both authenticates the client,
+ and provides the server with the client's ED25519 public key.
+ If the
+ message is correct, the Apple TV updates the AES IV by adding 0x01 to the last byte, and encrypts
+ its own public key as a <epk> plus <authTag>. It then
+ responds with a HTTP 200
+ and a plist containing the server <epk> and <authTag>, which
+ means that <K> (also known as the the session key)
+ is now registered in the AppleTV as a valid shared secret with the client.
The client can then (optionally)
+ authenticate the server by using the AES key and (modified) IV to decrypt the server <epk> with
+ authentication by <authTag> (true Apple clients will not continue to the next step unless the server
+ <epk> passes this test).
+ (Provided the server
+ has correctly communicated its ED25519 public key to the client in a response
+ to an earlier a POST /GetInfo request from the client, and the client does not care about authentication of
+ the server, decryption by the client of the server <epk> by the client can be skipped.)
+
+ At the end of the SRP procedure, client and server each know the other's
+ ED25519 public key, which is all that is needed to pass to the next step ("pair-verify").
+
After pair-setup-pin has
+ successfully finished, the client will never have to repeat it, provided that the server ED25519 public key
+ has not changed..
+
32
- These -parameters - do not seem to be used later in the protocol
These parameters + are used only for the client to confirm the authentication of the server, and are + never used again in the protocol
server → client
10.1a. RTSP pairing ("pair-setup" without pin, if the Server is not
+ password-protected)
+
+ This is a
+ simpler alternative pairing procedure that the client can use if the Server indicates that
+ it is not password-protected ("pw" = "false" in the DNS_SD announcement), but bit 27 in
+ its "features" bitstring ("supports Legacy Pairing") is set. (pair-setup can be skipped
+ completely if bit 27 is unset and password-protection is "off".)
+
+ The pair-setup POST request starts the procedure
+
+ client
+ → server
+ POST /pair-setup RTSP/1.0
+Content-Length: 32
+Content-Type: application/octet-stream
server → client
RTSP/1.0 200 OK
+Server: AirTunes/320.20
+Content-Type: application/octet-stream
+Content-Length: 32
The
+ pair-setup POST request is used to send the 32 byte client ED25519 public key
+ to the Apple TV (AirPlay server) as a binary message, and the server just reponds with its own public key. .
10.2.
- RTSP session authentication
+ RTSP session authentication ("pair-verify")
- Now,
-before
- initialing any audio, video or exchange with the AppleTV, each
+ At the
+ beginning of this part of the protocol, the client and server (in principle)
+ know each others ED25519 public keys. (Since the client will now again
+ send its public key to the server, it is
+ not even necessary that the server starts with this knowledge, unless it wishes to check if the client has
+ previously completed the pair-setup-pin or pair-setup process.)
Now, before
+ initializing any audio, video or exchange with the AppleTV, each
RTSP session must be authenticated. This means that after a TEARDOWN,
the same protocol must happen again (only the authentication, not the
pairing). The auth_secret <a> will now be used
@@ -627,7 +712,7 @@ Generate
- locally a random 32 bytes number and use a Curve25519 (ECDH)
algorithm to build a verifier key pair <v_pub> and
<v_priv>
- (32 bytes each).
+ (32 bytes each).
+ The Apple TV (AirPlay server) will likewise build <atv_pub> (and <atv_priv>,
+ which will not be revealed to the client). With knowledge of either (<v_priv>, <atv_pub>)
+ or (<atv_priv>,<v_pub>), an "ECDH secret" <secret> shared between client and server
+ can be created.
+
+
@@ -690,9 +782,12 @@
The
AppleTV
responds with a body containing 96 bytes of data. Again, this is NOT
- a plist, but just plain binary. The first 32 bytes are an AppleTV
- public key <atv_pub> and the remaining bytes (usually 64) are
- some data <atv_data> to be used in next step.
plist, but just plain binary. The first 32 bytes are the AppleTV
+ public ECDH key <atv_pub> and the remaining 64 bytes, which will here be called
+ <atv_data> must be used in next step (these 64 bytes of <atv_data> are in fact
+ the server's equivalent to the client <signature> described below, and they
+ will be described at the end of the next section).
+
server → client
The
AppleTV
should respond with an HTTP/RTSP 200 and the session (socket)
- is valid
+ is valid.
The recipe used by the server to create <atv_pub> can now be given.
+ It follows the same six steps as above,
+ except that in step 2, the server's <signed> uses the concatenation
+ of <atv_pub> and <v_pub>
+ which is in the opposite order from that used above by the client. In step 5, there is nothing
+ previously received by the server that corresponds to <atv_data> so only the server's
+ <signed> is encrypted to the 64 byte <signature>, using AES key and IV built as in steps 3 and 4.
+ This server <signature> is exactly what the client knows as <atv_data> in step 5.
+
+
server → client
-