Adobe Protected Streaming in Flash Media Server (swf verification, rtmpe)

[any ANONYMOUS forum user]

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.Contents
1 Encryption
2 SWF verification
3 Notes
4 References

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. 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 the algorithm relies on security through obscurity. 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 a DMCA takedown on one such tool named rtmpdump to try to limit its distribution, elading 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.