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. No matter how week is the protection used by adobe, almost any video can be recorded from screen using screen video capture software.

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

When selected at the server level, 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. 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, but with the down-side that there isn't actually any security.

In the past, some tools were able to capture RTMPE streams by taking advantage of a security hole within the Flash player object. Replay Media Catcher was the first software capable of downloading RTMPE streams, this feature was introduced by Applian Technologies in 2008. As of January 28, 2009, any newly installed copy of Replay Media Catcher does not support Adobe Secure RTMP Measures. Applian Technologies have resolved a dispute with Adobe Systems, without admitting any wrongdoing or liability, by agreeing not to circumvent any Secure RTMP Measures developed by Adobe.

Adobe fixed the security 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 the algorithm relies on security through obscurity. Amongst other things, this renders RTMPE vulnerable to Man in the Middle attacks.

Tools which have a copy of the well-known constants extracted from the Adobe Flash player are able to capture RTMPE streams, a form of the trusted client problem. Adobe issued DMCA takedowns on RTMPE recording tools including rtmpdump to try to limit their distribution. However in case of rtmpdump, this lead to a Streisand effect.

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)
• rtmpdump 2.1+ (Source code and binaries)
• 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