Tumbled Logic

Apr 20 2009

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.


blog comments powered by Disqus
Page 1 of 1