- Requirements
Prerequisite knowledge
This article assumes that you have basic knowledge of using the Adobe Media Server and know how to run a Flash based SWF client.
Required Products
Adobe Media Server Professional
Flash Media Live Encoder

Additional required other products
An OSMF based SWF client for playback (Learn about OSMF here)
User level


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.

What is SWF Verification?
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

Set up Adobe Media Server
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:
Figure 1. Testing the AMS installation with the Adobe Media Server start page.

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

Configure Protected HTTP Streaming
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.
Figure 2. The location directive specifying the EncryptionScope and ProtectionScheme.
Restart the AMS Server.
This enables Protected HTTP Streaming without SWF Verification.


Create whitelist files
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 :
Figure 3. Using the command prompt to copy the client SWF into the whitelist folder.
 You should see a .whitelist file being created.
Figure 4. The .whitelist file you created from the command prompt.
Once the .whitelist or .airwhitelist files have been generated copy them into a common folder anywhere on the server.

Configure SWF Verification
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.
PHDSSWFVerification true PHDSSWFWhiteListFolder “path of the whitelist folder”
Figure 5. Configuring SWF Verification with PHDS.
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:
EncryptionScope content
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).

Verify SWF Verification
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:
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.
Configure SWF Verification for live streams
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:

Troubleshooting issues
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.

Where to go from here
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: