Drafting a secure RTP transport profile
Yes, I know SRTP exists, but it solves a rather different problem.
What I’m aiming at here is a protocol wherein the lifetime of the stream can exceed the lifetime of the key—that is, authenticated access to an ongoing stream.
My rough notes so far are that:—
In order to access the SDP for a stream, the client must authenticate itself to the server (WWW-Authenticate, quite probably?)
The SDP the client receives is dynamically-generated, and includes a key K₀, a sequence Kseq and an expiry timestamp Klife₀.
If Klife₀ is within a close enough distance to the current time, the server will also send a second key K₁, Kseq+1 and Klife₁. If a client’s access would have expired by the time Klife₀ arrives, no keys beyond K₀ would be sent (and so on).
At any point, re-requesting the SDP (e.g., via HTTP GET or through an RTP DESCRIBE) causes the above steps to be repeated, that is, when the client detects that it’s nearing Klife₀, it issues a fresh request to obtain the details for K₁ if it doesn’t already have them.
The actual media streams are encrypted using a simple block cipher (nothing too intensive) and packets include a header indicating the current Kseq value.
The keys can change often enough that a heavyweight cipher isn’t necessary—the focus is on preventing unauthorised access to content which must be paid for (i.e., pay-TV), rather than (as with SRTP) encrypting confidential information.
Some kind of secure key exchange mechanism will be required. Although the keys will be embedded in the SDP, if the SDP can simply be sniffed by a third party, all bets are off. Perhaps the key block in the SDP should be an encapsulated portion of a DH exchange? Needs to be kept small, as SDP size is limited.
The intention is that the authentication provides access to the key, rather than generates the key—in a multicast/broadcast scenario, all users would have the same key.
It should be possible for third parties to passively relay the secured stream without needing to decrypt/re-encrypt.