Protected Streaming

Protected Streaming is a DRM technology by Adobe. The aim of the technology is to protect digital content (video or audio) 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 Hulu desktop player and 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.

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 the case of rtmpdump, this led 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