SWF verification for Protected HTTP Dynamic Streaming

In this article you will understand how SWF verification for HTTP streaming works in Adobe Media Server (AMS), and how you can prevent unauthorized SWF clients from accessing your content. By using SWF verification you can stop someone from creating their own SWF clients to stream your content.

SWF Verification protects your content by preventing unauthorized clients from accessing it. To enable SWF Verification for HTTP streaming, you need to enable Protected HTTP Streaming (PHDS).

PHDS is used to serve protected content to Flash Player and AIR-based clients, over HTTP, without using a DRM license server. With PHDS, when Adobe Media Server encrypts and packages the content, it generates a license using the Shared domain certificates and embeds it into the DRM metadata of the content stream that is delivered with the media. The Flash Player and AIR clients then retrieve the license from the content stream and use it for decryption, eliminating the need to communicate with a license server.

To enable SWF verification you create a list of "authorized" SWF files, called a whitelist. These files are specified in the embedded license and sent to the client inside the DRM metadata. On the client, SWF verification is enforced by Adobe Access runtime inside the Flash Player and AIR. During DRM authentication, Flash Player or AIR attempt to verify the SWF hash in the DRM metadata with the SWF that is trying to access the resource. If the verification fails, Flash Player or AIR throws a runtime error (3310) and the client stops requesting the content.

Difference between SWF Verification for RTMP and SWF Verification for protected streaming

Adobe Media Server supports a version of SWF Verification for RTMP connections. In RTMP SWF Verification, AMS is provided with a copy of the authorized SWF clients. When a client SWF connects to AMS, the server verifies the SWF against the copies present on the server and disconnects clients that are sending invalid bytes.

1. There are some major differences between the RTMP method of SWF verification and protected streaming based SWF verification:
2. In the RTMP method, AMS verifies the client SWFs that connect to the server and disconnects any client sending invalid bytes. In the protected streaming based method, AMS embeds the list of authorized SWF clients in the DRM Metadata and sends it to the client. SWF verification is then enforced by Adobe Access runtime inside Flash Player or AIR.
3. RTMP SWF Verification verifies the SWF client only at the time the connection is made. Once a client is authorized it can access any content. On the other hand, in protected streaming based SWF verification, the list of authorized clients is embedded in the DRM metadata of the content stream. As each stream is embeded with different DRM metadata, SWF verification is enforced for each stream.
4. As RTMP SWF verification only verifies the SWF client at the time of connection, an authorized client may request streams and then pass them on to other unauthorized clients. In protected streaming based SWF verification, as the list of authorized SWF clients is embedded in the DRM metadata, no unauthorized client will be able to play the content.
5. Protected-streaming-based SWF verification is supported by protected RTMP (pRTMP) as well.  Protected RTMP can be used to encrypt and deliver protected content to Flash and AIR based clients over the RTMP protocol. You can read more about pRTMP here.

Player Binding for HTTP Live Streaming

Adobe Media Server supports whitelist-based player binding for HTTP Live Streaming (HLS). This feature is similar to the PHDS/pRTMP SWF Verification feature.

Using Adobe Media Server you can deliver protected streams to iOS based clients over HTTP using Protected HTTP Live Streaming (PHLS). PHLS is a non-DRM based protection scheme similar to PHDS. When player binding is enabled with PHLS, AMS will add the list of identifiers picked up from the .airwhitelist files and embed it into the DRM metadata. SWF verification is then enforced by the Adobe Access SDK on the iOS client. You can find more information regarding player binding here.

How to configure SWF Verification?

To set-up SWF verification there are 5 basic steps :

1. Set up Adobe Media Server
2. Configure Protected HTTP Streaming (PHDS)
3. Create whitelist files
4. Configure SWF verification
5. Verify SWF verification

The first step in the process is to download and install Adobe Media Server (AMS). Adobe Media Server is available for Windows and Linux platforms, and can be downloaded from here. Once you have downloaded and installed the server, you can test your installation by launching the AMS start page

Verify Installation

On the server open a browser of your choice and go to : http://localhost:8134/

You should see the following page:

Try to play different streams. If you’re able to playback the streams successfully, your server is properly installed.

To use SWF Verification, PHDS needs to be enabled. You can read more about Protected HTTP Streaming here.

To enable PHDS, open the httpd.conf file in a text editor. The httpd.conf file is located in the root_install/Apache2.2/conf folder.

In the httpd.conf file search for the location directive. Enable PHDS by uncommenting the following lines :

EncryptionScope server

ProtectionScheme phds

The EncryptionScope tag specifies that the protection will be applied at the server level. The ProtectionScheme specifies the scheme as PHDS.

Restart the AMS Server.

This enables Protected HTTP Streaming without SWF Verification.

To enable SWF Verification we create a list of authorized SWF files called a whitelist.

Using the whitelist tool

To generate the whitelist, you use the Whitelist tool. The tool is located in the root_install/tools/Whitelist directory. The whitelist tool takes SWF files, AIR certificate files and AIR signature files and creates a SHA256 hash for each file. The tool writes the hashes as Base64 encoded text to one or more output files with the .whitelist and .airwhitelist extensions.

To use the tool, copy the client SWF into the whitelist folder. In the command prompt, navigate to the the whitelist folder and run the following command:

Whitelist –in

For example :

 You should see a .whitelist file being created.

Once the .whitelist or .airwhitelist files have been generated copy them into a common folder anywhere on the server.

Finally, you need to configure SWF Verification with PHDS. To perform this action, navigate to the location directive in the httpd.conf file.

Under the PHDS configuration tags, you need to add the following :

The PHDSSWFVerification tag specifies that the SWF Verification is turned on. The PHDSSWFWhiteListFolder tag specifies the folder where the .whitelist and/or .airwhitelist files are located. This path can be either an absolute path or relative to the Apache2.2 folder.

Save the file and Restart the server.

This configuration will enable SWF Verification for all streams.

Configure content-specific SWF Verification

You can configure content-specific SWF Verification by changing the encryption scope to content in the httpd.conf file:

In this case, encryption configurations specified in the jit.conf file will be used. If there are two sets of content, say A and B and if you want to apply different set of SWF Verification settings for set A and B, then you can place the content in two different paths and modify their jit.conf files appropriately.

You can find the configurations to set SWF Verification at content level here.

When SWF Verification is enabled, only the SWF client whose hashes are present in the whitelist folder will be able to play back the protected content. On any unauthorized client, Flash Player/AIR will throw a runtime error (3310).

You can verify if SWF Verification has been enabled correctly, by performing two checks.

On a SWF client authorized to access the content, try to play a stream as follows:

http://ams-server-ip/hds-vod/sample1_1000kbps.f4v.f4m

The client should be able to play back the stream.

Now, on any unauthorized SWF client try to playback the same stream. This time the client will be unable to play the stream and an error will be thrown.

Configuring SWF Verification for live streams is similar to that used for on-demand streams.

Here are the steps :

1. In the httpd.conf file search for the <Location /hds-live> location directive.
2. Enable PHDS by adding the following lines :
   HttpStreamingEncryptionScope server
HttpStreamingProtectionScheme PHDS
3. Add the SWF Verification tags after HttpStreamingProtectionScheme :
   PHDSSWFVerification true
PHDSSWFWhiteListFolder “path of the whitelist folder”
4. Place the .whitelist and/or .airwhitelist files under the whitelist folder.
5. Restart the AMS Server.
6. Use the Flash Media Live Encoder to publish a live stream to the livepkgr application.
   FMS URL: rtmp:///livepkgr
Stream: livestream%i?adbe-live-event=liveevent
7. On a SWF client authorized to access the content, playback a stream as follows:
   http://ams-server-ip/hds-live/livepkgr/_definst_/liveevent.f4m

SWF Verification not enabled

1. Ensure that the AMS server was restarted once the configurations were added.
2. Ensure that the whitelist folder parameter is specified. If the whitelist folder parameter is not specified, the default folder location will be applied. The default location for configurations in httpd.conf is the folder containing the media. You can find more information here.
3. Ensure that the whitelist folder is correctly specified and is not empty. An empty whitelist folder will result in an error.
4. Increase the log level for Apache error logs to debug level. Check if any errors are reported.
5. If you have provided the relative path for the whitelist folder, verify that the relative path is correct. Change the path to an absolute path and retry. It may happen that the relative path is incorrectly specified.
6. Verify you have a proper AMS license to use PHDS and it’s features. The default licenses are installed in the root_install/licenses folder.
7. If SWF Verification is enabled in the jit.conf file, ensure that the jit.conf is not malformed. It should be a valid XML file.

Trouble playing back content

1. Ensure that there are no errors in the Apache error logs.
2. Ensure that the SWF client is authorized to play the content, i.e the .whitelist/.airwhitelist file for the client is present in the whitelist folder mentioned.

SWF Verification is an easy and quick way to prevent unauthorized clients from streaming your content.

SWF Verification can be applied at either the server level or the content level. SWF Verification can also be configured for live streams.

Learn how to configure SWF Verification at content level for On-Demand streams here.

Learn how to configure SWF Verification at content level for live streams here.

Learn about Player Binding for HTTP Live Streaming here.

Learn more about Adobe Media Server:

• See what’s new in Adobe Media Server
• Stream video over HTTP to iOS devices
• Configure content protection for HTTP Live Streaming