Protected Streaming

Protected Streaming is a DRM technology by Adobe. It is used to give the impression that digital content (video or audio) is being protected from unauthorized use.

Protected Streaming consists of many different techniques; basically there are two main components: encryption and SWF verification.

This technique is used by the RTE Player.

Encryption

All content is encrypted by the Flash Media Server "on the fly". This means there is no encryption of the source file needed (which is different from Microsoft DRM, for instance). For data transmission, a special protocol is used: RTMPE or RTMPS.

RTMPS uses SSL-encryption, RTMPE was designed to be simpler than RTMPS, by removing the need to acquire an SSL Certificate. Unfortunately, Adobe did not consult with cryptographic experts before designing the RTMPE protocol. RTMPE makes use of well-known industry standard cryptographic primitives consisting of Diffie-Hellman key exchange and HMACSHA256, generating a pair of RC4 keys, one of which is then used to encrypt the data sent by the server (such as the audio or video stream), whilst the other key is used to encrypt any data sent to the server. RTMPE causes less CPU-load than RTMPS on the Flash Media Server. In the past, some tools were able to capture RTMPE streams by taking advantage of a security hole within the Flash player object. Adobe fixed this issue, in January 2009, but has not fixed the security holes in the design of the RTMPE algorithm itself. Analysis of the RTMPE algorithm shows that there is no "security" of any kind: the algorithm relies entirely on information that can be accessed publicly (such as the SWF file) and on "magic constants". Key to the failure of the RTMPE algorithm is that there is no reliance on privately-held information, such as a private SSL key as used in RTMPS. Thus, RTMPE is wide open to Man in the Middle attacks, is a classic example of Security through obscurity, and thus cannot in fact be deemed to be a "Digital Copyright Protection Mechanism" in any way, shape or form.

Tools which have a copy of the well-known constants extracted from the Adobe Flash player are still able to capture RTMPE streams, which is a form of the trusted client problem. Adobe issued a DMCA takedown on one such tool named rtmpdump to try to limit its distribution (which has had completely the opposite effect) . Issuing such a DMCA takedown notice when the security of the RTMPE protocol is so transparently nonexistent is a questionable practice. However, every single project on sourceforge was placed at risk by Adobe's actions, and, with no access to technical or legal resources, sourceforge was forced to comply.

SWF verification

The Adobe Flash player uses a well-known constant, appended to information derived from the SWF file (a hash of the file and its size), as input to HMACSHA256. The HMACSHA256 key is the last 32 bytes of the server's first handshake packet. Flash Media Server uses this to limit access to those clients which have either had access to the SWF file (or have been given a copy of the hash and the size of the SWF file).

All officially allowed clients (which are in fact *.swf Files) need to be placed on the Flash Media Server. Any unknown client requesting a connection will receive a "connection reject".

The combination of both techniques ensures that streams cannot be sniffed and stored into a local file. SWF verification is intended to prevent manipulated clients from accessing the content, but does not achieve this goal. Third party clients are free to write the unencrypted content to a file simply by knowing the hash of the SWF file and its size. Adobe's own implementation of Flash Player is one client which does not allow saving into local files.

Thus, the only possible way left to restrict connections to the Flash Media Server is to use a list of known hosts, to avoid that the whole player (the Flash client) is placed on a foreign site. Even this has no real benefit for mass-distributed files, as any one of the known hosts could take a copy of the data and re-distribute it at will. Thus, the "known host" security is only useful when the known hosts can in fact be trusted not to re-distribute the data.

References

• Whitepaper by Adobe
• RTMPE (Adobe LiveDocs)
• RTMPS (Adobe LiveDocs)
• Source code of rtmpdump v1.6 by Andrej Stepanchuk
• RTMPE specification, generated from the rtmpdump source code
• RTMPE specification, mirror of the above
• RTMFP encryption mechanism (DRAFT), reverse engineered from scratch