RTMP encryption

The news that the BBC has started "encrypting" its RTMP streams came, in one of those coincidences, just as I'd decided to work on adding RTMP support to Gnash. So even when Gnash's RTMP video streaming works, it will still be legally difficult, if not impossible, for licence fee payers who care about software freedom to use the BBC's iPlayer.

Like the CSS technique for DVDs, "encryption" is a misnomer here. Both the technique and the key are well known. The XBMC rtmpdump software already supports it, but leads a shadowy existence after a takedown notice from Adobe. Integrating it into Gnash would be technically trivial. But then it becomes undistributable in many countries.

Just like any other weak and easily breakable encryption technology, it is nothing more than a facade to gain the legal protection of the DMCA and similar laws. Technically you can see it, but because that would involve "breaking" "encryption", you aren't allowed to.

But what can we do about it? How much of an implementation is legally permissible? Can we implement everything but leave users to find out the key on their own? Or write a separate plugin to be hosted in a safe country?

just wrap librtmp

Now that rtmpdump's protocol driver is available as librtmp under LGPL, why not just use that? You don't even need to distribute the code then.


This is an interesting idea, but there are a couple of problems with it:

a) it introduces a dependency for Gnash that most distros can't distribute, so there would be no RTMP support, encrypted or otherwise, unless users can get hold of librtmp.

b) integrating librtmp into Gnash's architecture isn't straightforward.

It's still worth considering, though, especially if the alternatives don't work.

talk to us

There's no reason to work in isolation. We've now successfully adapted librtmp to ffmpeg, mplayer, and XBMC. If you need changes to fit it in, tell us what you need.

One possibility is to bundle a -DNO_CRYPTO build of librtmp, and provide hooks for loading the crypto functions as a separate module. This can all be done trivially; certainly for a lot less effort than starting over from scratch.


Thanks for the offer! When I have time to work on Gnash's RTMP again (hopefully in a couple of weeks) I'll check it out.

Surely implementing

Surely implementing everything but leaving out the key seems a sensible first step.
Allow the key to be put in GNASHRC. Someone will figure how to make the key available.

Keys aren't your problem,

Keys aren't your problem, they are generated randomly for each session. It's only a question of implementing the correct algorithms, all of which are available off-the-shelf. Some are even public domain.


From what I understood, the session keys are generated using a hash of the SWF together with fixed player "key" (and maybe some other things that I've forgotten). Although all of those things are easy to do, at some point the implementation evidently becomes possible to attack using DMCA legislation. The question was, how much can you implement without becoming vulnerable to that?