RTMPE is definitely not a "Copyright Protection" mechanism.
An analysis of RTMPE (see "Analysis" section) shows that RTMPE does nothing more than what SSL already does (provide end-to-end secrecy, except without the protection against man-in-the-middle attacks - RSALabs on DH, para 5) and simply mathematically links a publicly-downloadable and publicly-obtainable SWF file to the connection.
Bottom line: All the information required to obtain the content is publicly available. There is no "security".
If the information isn't publicly available (such as the SWF file to be executed in the web browser) then the content cannot be obtained, either.
Adobe claims that SWF verification is somehow "secure". Anyone reading this who has bought into Adobe Technology on the basis of "security" or "protection" is advised to initiate legal action against Adobe,seeking compensation and damages for deceiving them about the level of "protection" of their Copyright material.
From Adobe's Web Site:
Quote:
Originally Posted by adobe.com
'(swf verification) ensures that only your SWF or AIR files can connect to your application or content on Flash Media Server'.
|
This is false. The correct interpretation is:
"if anyone can obtain the publicly-available SWF or AIR file (or a hash of it, and knows the SWF or AIR file's size) they can also connect to your application or content".
Are there any 'encryption' keys in RTMPE?
No, there are no encryption keys in RTMPE. There are however three magic constants which are used as input. And, remember, also, the publicly accessible SWF file - the one which you put on the web site to view the content - is used as input to the algorithm as well (or, at least, its hash and its size).
So if you want to get genuinely stupid, and consider the sentence "Genuine Adobe Flash Player 001" to be a quotes key quotes, then by that definition, so is the publicly accessible SWF file also a quotes encryption key quotes.
This raises some hilarious implications:
How can you claim that a key is secret, yet make it publicly available on the internet? If you want to keep this "key" secret, surely you should go after all web browser distributors, and everyone who has HTTP cacheing technology, DEMANDING that they "protect" - remove - SWF files from caches.
This latter is quite easily achieved. You just block *.swf files. Actually, all Free Software HTTP Proxy and Web Browser projects should not risk being subjected to DMCA takedown notices and should block all swf files, just to be on the safe side.
... after all, it's not like they can analyse the content being streamed by the SWF file, because that would require either reverse-engineering
the SWF file on-the-fly in order to find out if it uses RTMPE, or setting up a complex system of analysing network traffic (again, which would
be, like, illegal, like, cos you'd have to, like actually identify RTMPE and would need to, y'know, know the algorithm?).
Presumably, though, on detection of RTMPE, then, well, by that time, it's too late: the browser will have already received and be executing the SWF file. So, presumably, right, like that joke computing language which had a "GO FROM" statement and an "IF THEN ELSE UNLESS" construct, you'd have to somehow undo the past, and, presumably, if that wasn't possible, try to hide the fact that you were unable to predict the future, by deleting incriminating evidence from the user's machine and then crashing it.