Understanding Adobe's Content Protection Offerings

As we discussed in a previous post, content protection is a key tool that can be used to monetize premium video online.

Adobe offers a couple of ways to achieve this; which one you use will depend on your specific needs, content and infrastructure. In this post, I describe some of these options at a high level, hopefully addressing some of the misconceptions (or is it FUD?) that exist out there.

For those of you who use Flash Media Server to stream content to Flash Player, in addition to advanced features such as Dynamic Streaming you have the option of also using the built-in content protection features. These are in vary broad use today by some of the leading streaming content providers around the world, [[[[including Hulu, Amazon and M6 ---- TBD can we use these here? It is easy for anyone to see that they are using RTMPE so we're not giving anything away that could help a hacker]]]].

The first of these features is RTMPE, the encrypted version of Adobe’s Real Time Media Protocol. RTMPE provides session-based protection, which means that all data between client and server is encrypted using a different key that is negotiated for each “session”. RTMPE will encrypt all data that goes in the “pipe”, whether it’s video content, data or headers. This is used to block tools that intercept the stream or try to impersonate a valid client in order to make unauthorized use of the content, such as making an unprotected recording (aka ripping).

In addition, FMS also supports SWF Verification, which is used to limit playback of the content to only the video player applications (SWF) that have been authorized. This works best when used in combination with RTMPE: once a secure tunnel has been established between client and server, the Flash runtime computes a hash of the video playback SWF that’s running and then sends that hash securely to the server, where it is compared against a list of approved SWFs; if there’s no match, the connection is rejected.

If this isn’t your first time on this blog, you’ve probably seen other posts regarding Flash Access. To recap, Adobe Flash Access is an advanced content protection solution that we are rolling out in the first half of this year and will work with Flash Player 10.1 and AIR 2.0. (This product was initially launched under the name Flash Media Rights Management Server, but the 2.0 version will adopt the new name and a much improved architecture.)

Unlike the features described above, content protection using Flash Access is not tied to FMS; while you can use both products together to get all the benefits of streaming plus advanced control over content consumption, you can also use each one independently. For instance, you can use Flash Access to protect progressive downloads or with the upcoming HTTP Dynamic Streaming (formerly “Project Zeri”).

With Flash Access, the operating principle is a bit different than with RTMPE. The content is persistently protected, ie it is encrypted once and remains protected wherever it goes. This makes it cache-friendly: whether the content is cached at the edge on the CDN or in the browser cache, it is encrypted and does not represent a security risk. Flash Access also allows you to define a number of usage rules, which are enforced by the client and can help support your business model, whether it’s video on demand, rental, subscription or download to own, to name a few of the more popular models out there.

This requires a few changes to the content workflow: encoded content must be run through a “packager” that encrypts the content. The packager is fileformat-aware: rather than blindly encrypt headers and metadata, it creates a valid file (e.g. F4V) with an encrypted payload. This means that the files can be streamed or downloaded like any other file over any protocol, whether it’s RTMPE, HTTP or something else.

However, once the content arrives in the player, you have the bits but not the rights to play the content. This triggers a request to a “license server”, hosted either by the content distributor or by a service provider on their behalf. The license server will only issue a content license, which contains the key necessary to play back the content, to clients “in good standing”, ie it will reject attempts from rogue clients.

SWF verification is also supported, but now the “whitelist” of approved SWFs can be included in the content license and is enforced by the client. All the the really sensitive operations, such as cryptographic operations or rules enforcement, happens in the native code in the runtime where it is difficult to hack. The application or ActionScript code acts as a sort of remote control, triggering operations such as license acquisition and registering to receive events that may be surfaced to the user.

I hope this provides a good overview and helps identify when each technology may be most appropriate. If you’d like to learn more about the content protection features in FMS, check out the article on Adobe Developer Connection. You can also find more details about Flash Access, including an in-depth whitepaper, on our product page at http://www.adobe.com/products/flashaccess.

F
Twitter: @florianatadobe

Show Comments

Hide Comments

Comments are closed.