|
Use protected RTMP (pRTMP) to encrypt and deliver on-demand
content to Flash Player and AIR.
Note: Protected RTMP isn’t a protocol. It delivers encrypted content
over the RTMP protocol.
System requirementsProtected RTMP is supported in origin-only configurations.
Unlike RTMPE, pRTMP does not work in an edge-origin configuration.
Applications that share media files must use the same
protected RTMP configuration settings for the shared files.
Flash Player 11.0 and AIR 3.0 are required to play protected
RTMP content. Protected RTMP supports all the on-demand file formats and codecs that RTMP supports
except F4M, RAW, and F4F.
Note: In Flash Media Server 4.5.1, protected RTMP is supported for
VOD streaming, it is not supported for live streaming.
About protected RTMPFlash Media Server encrypts on-demand media files and embeds
a Flash Access 3.0 license in the DRM metadata of the content. Flash
Player and AIR clients communicate with Flash Media Server to play
the media. Protected RTMP does not require a license server; the
license is embedded in the content metadata and a client receives
it along with the media.
Protected RTMP is more secure than RTMPE because it uses Flash
Access 3.0 DRM content protection. Protected RTMP encrypts the content
whereas RTMPE protects the communication channel. Because data is
unencrypted, companies like comScore and Nielsen can measure protected
RTMP video.
Because the content is encrypted, unauthorized replay is impossible.
Protected RTMP content can be decrypted only by Flash Player and
AIR clients that have the shared domain private key.
There is no way to use an RTMPE connection between servers and
decrypt the content on Flash Media Server. Different applications
that access common media files must have consistent setup with respect
to Protected RTMP. That is, you should not access the same media
file over both protected and unprotected RTMP.
Separate applications that include common media files must have
consistent settings with respect to Protected RTMP. When FMS receives
requests for media file playback (VOD) it applies the application-specified
protection to the media and then caches it in memory. Each time
the server receives a new request for an already cached media file
it compares the protection settings of the cached media with the
settings of the application in the new request. If those settings
are inconsistent FMS replaces the cached media with content processed
according to the settings of the application of the current request
and then sends the media to the client. FMS generates an error log
entry every time it identifies inconsistency between cached media
settings and requested media settings.
Protected RTMP simplifies deployment and increases security because:
Flash Media Server is the only server required.
No license server is required.
No domain server is required.
All media can be packaged with the same common key.
Content is encrypted with Flash Access 3.0 DRM protection.
Protected RTMP uses 128-bit AES encryption. RTMPE uses 128-bit
RC4.
Configure protected RTMP at the vhost, application, or application
instance level. Use the Application.xml file, Server-Side ActionScript,
and the Authorization Plug-in to configure protected RTMP.
Quick start: Use protected RTMP to play on-demand mediaTo complete this tutorial, install the following software:
Configure protected RTMP on Flash Media ServerConfigure protected RTMP for the VOD application.
Open fmsrootinstall/applications/vod/Application.xml
in a text editor.
Add the <ProtectedRTMP enabled="true"></ProtectedRTMP> element.
The Application.xml file looks like this:
<Application>
<ProtectedRTMP enabled="true"></ProtectedRTMP>
...
</Application>
Save and close the file.
If the VOD application is running, close it to reload the
Application.xml file. If the Flash Media Server Start Screen is
open, the VOD application is running. Closing the Start Screen closes
the VOD application (unless another client is also connected to
the VOD application).
Play on-demand mediaDouble-click the Flash Media Server Sample Video
Player to open it in a browser: fmsrootinstall/samples/videoPlayer/videoplayer.html.
Click any link in the /applications/vod/media list. Every
file that the VOD application streams uses protected RTMP.
Configure protected RTMPYou can configure protected RTMP in the following locations:
Use the Application.xml file to configure protected RTMPTo configure protected RTMP, add a <ProtectedRTMP> section
to the Application.xml file at the application level or at the vhost
level and set the enabled attribute to "true".
The other pRTMP parameters have default values. You can use the
default values or set the parameters to new values. The following
is a sample <ProtectedRTMP> section:
<Application>
<ProtectedRTMP enabled="true">
<CommonKeyFile>phds/common-key.bin</CommonKeyFile>
<UpdateInterval>60</UpdateInterval>
<SWFVerification enabled="true">
<WhiteListFolder>whitelists</WhiteListFolder>
</SWFVerification>
</ProtectedRTMP>
</Application>
Use the following parameters in an Application.xml file to configure
protected RTMP:
Parameter
|
Description
|
Default
|
CommonKeyFile
|
A relative path to a file containing a base key.
The path is relative to the folder that contains the Application.xml
file.
The server generates the base key file during installation.
The server uses the base key (along with the content ID) to generate the
final content encryption key. The key data is scrambled and Base64
encoded using the scramble tool. The server generates the content
ID automatically.
|
rootinstall/phds/common-key.bin
|
UpdateInterval
|
Optional configuration that specifies how often
(in minutes) the server updates the DRM metadata.
|
60
|
SWFVerification
|
Container for SWFVerification. To enable SWF
verification, set the enabled attribute to "true".
|
"false"
|
WhiteListFolder
|
The folder that contains the SWF whitelist for
SWF verification. The folder can contain more than one whitelist
file. Relative paths are relative to the application folder.
|
The folder containing the application folder.
|
Use the Authorization plug-in to configure protected RTMPTo configure protected RTMP at the plug-in level, write
code in the E_APPSTART event to set the F_APP_PRTMP field
to true. The other pRTMP fields have default values. You can use
the default values or set the fields to new values. Protected RTMP
settings in the Application.xml file are overridden in the Authorization plug-in.
The E_APPSTART event is an application-level
event that supports reading all application-level fields, including
the following:
Field
|
Description
|
Read/Write
|
F_APP_URI
|
The URI of the application to which the
client connected. The value does not include the server name or
port information.
|
Read-only
|
F_APP_NAME
|
The application name.
|
Read-only
|
F_APP_NAME
|
The application instance name.
|
Read-only
|
The E_APPSTART event supports the following
new fields for protected RTMP:
Field
|
Description
|
Read/Write
|
F_APP_PRTMP
|
A Boolean value indicating whether RTMP streaming
is protected.
|
Read/Write
|
F_APP_PRTMP_COMMON_KEY_FILE
|
A string to specify the path to the common
key file. The path can be absolute or relative. Relative paths are
relative to the location of the application folder.
|
Read/Write
|
F_APP_PRTMP_UPDATE_INTERVAL
|
A number to specify how often (in minutes)
the DRM metadata will be updated.
|
Read/Write
|
F_APP_PRTMP_SWF_VERIFICATION
|
A Boolean value indicating whether SWF Verification
is enabled.
|
Read/Write
|
F_APP_PRTMP_SWF_WHITELIST_FOLDER
|
A string to specify the path to the whitelist folder
for SWF verification.
The path can be absolute or relative.
Relative paths are relative to the location of the application folder.
|
Read/Write
|
F_APP_PRTMP_SWF_WHITELIST
|
A string containing one or more SWF digests, separated
by '\n'. SWF digests are sha256 hashes of the SWF, base64 encoded.
You generate a whitelist using the whitelist tool that ships with FMS.
This string can also contain the comments and empty lines that are
in the whitelist generated by the tool, which are ignored.
|
Read/Write
|
F_APP_PRTMP_AIR_WHITELIST
|
A string containing one or more AIR identifiers, separated
by '\n'. AIR identifiers are derived from the signature.xml file
that is used to sign an AIR app. You generate a whitelist using
the whitelist tool that ships with FMS. This string can also contain
the comments and empty lines that are in the whitelist generated
by the tool, which are ignored.
|
Read/Write
|
The E_PRTMP_WHITELIST event is an application-level
event that FMS calls every n minutes (according to the update
interval), enabling you to update the SWF/AIR whitelists through
the F_APP_PRTMP_SWF_WHITELIST and F_APP_PRTMP_AIR_WHITELIST fields.
Use Server-side ActionScript to configure protected RTMPUse the following Server-side ActionScript properties to
configure protected RTMP:
Property
|
Data type
|
application.prtmpEnabled
|
Boolean
|
application.prtmpCommonKeyFile
|
String
|
application.prtmpUpdateInterval
|
Int
|
application.prtmpSWFVEnabled
|
Boolean
|
application.prtmpSwfWhitelistFolder
|
String
|
Note: The prtmpCommonKeyFile and prtmpSwfWhitelistFolder properties
specify a path to a file or folder. The server resolves relative
paths to an application directory.
These properties are filled in by values retrieved from configuration
files during the application.onAppStart() event.
You can also set values in this event, as follows:
application.onAppStart = function()
{
trace ("----------prtmp on start----------");
trac e("prtmp " + application.prtmpEnabled);
trace("prtmpCommonKeyFile " + application.prtmpCommonKeyFile);
trace("prtmpUpdateInterval " + application.prtmpUpdateInterval);
trace("prtmpSwfVerification " + application.prtmpSWFVEnabled);
trace("prtmpSwfWhitelist " + application.prtmpSwfWhitelistFolder);
trace ("------------prtmp on start------- -");
application.prtmpEnabled = false;
application.prtmpCommonKeyFile = "TEST ";
application.prtmpUpdateInterval = 12000 ;
application.prtmpSWFVEnabled = true;
application.prtmpSwfWhitelistFolder = "";
}
Trace the new values in the application.onConnect() event:
{
trace("----------prtmp on connect----------");
trace("prtmp " + application.prtmpEnabled);
trace("prtmpCommonKeyFile " + application.prtmpCommonKeyFile);
trace("prtmpUpdateInterval " + application.prtmpUpdateInterval);
trace("prtmpSwfVerification " + application.prtmpSWFVEnabled);
trace("prtmpSwfWhitelist " + application.prtmpSwfWhitelistFolder);
trace("------------prtmp on connect--------");
}
The previous code prints an application.log file similar to the
following:
#Version: 1.0
#Start-Date: 2011-10-19 12:20:41
#Software: Adobe Flash Media Server 4.5.1 d430 x64
#Date: 2011-10-19
#Fields: date time x-pid x-status x-ctx x-comment
2011-10-19 12:20:41 7832 (s)2641173 ----------prtmp on start---------- -
2011-10-19 12:20:41 7832 (s)2641173 prtmp true -
2011-10-19 12:20:41 7832 (s)2641173 prtmpCommonKeyFile c:\Program Files\Adobe\Flash Media Server 4.5\conf\_defaultRoot_\_defaultVHost_\streamtest\phds\common-key.bin -
2011-10-19 12:20:41 7832 (s)2641173 prtmpUpdateInterval 3600000 -
2011-10-19 12:20:41 7832 (s)2641173 prtmpSwfVerification false -
2011-10-19 12:20:41 7832 (s)2641173 prtmpSwfWhitelist c:\Program Files\Adobe\Flash Media Server 4.5\conf\_defaultRoot_\_defaultVHost_\streamtest -
2011-10-19 12:20:41 7832 (s)2641173 ------------prtmp on start-------- -
2011-10-19 12:20:41 7832 (s)2641173 ----------prtmp on connect---------- -
2011-10-19 12:20:41 7832 (s)2641173 prtmp false -
2011-10-19 12:20:42 7832 (s)2641173 prtmpCommonKeyFile c: \Program Files\Adobe\Flash Media Server 4.5\conf\_defaultRoot_\_defaultVHost_\streamtest\TEST -
2011-10-19 12:20:42 7832 (s)2641173 prtmpUpdateInterval 12000 -
2011-10-19 12:20:42 7832 (s)2641173 prtmpSwfVerification true -
2011-10-19 12:20:42 7832 (s)2641173 prtmpSwfWhitelist c:\Program Files\Adobe\Flash Media Server 4.5\WhiteListFolder -
2011-10-19 12:20:42 7832 (s)2641173 ------------prtmp on connect-------- -
Tune server performanceThe pRTMP operations that use the most CPU power are generating
the DRM metadata and generating a license. Flash Media Server generates
DRM metadata the first time a client requests a media file. The
server caches the metadata and reuses it for subsequent request
for the same media file.
The media license in the DRM metadata imposes a 24-hour time
limit on media playback from the point at which the license was
generated. Therefore, the server refreshes the license periodically
and generates new DRM metadata with a new time-stamp. Configure
the <UpdateInterval> parameter to control
how often the server generates DRM metadata. The default value is
60 minutes. To use less CPU power, generate the license less frequently.
Certificates and policy filesAll certificates and the policy file for protected RTMP
are installed to the Flash Media Server rootinstall/phds folder.
Add shared domain certificatesFlash Media Server uses shared domain certificates (.cer
files) for protected RTMP. The server installs with three shared
domain certificates. It uses different certificates for desktop,
mobile, and set-top.
In the event of a security breach, Adobe will release a security
alert telling you to download new shared domain certificates.
To add a shared domain certificate, copy it to the rootinstall/phds/sd folder.
Understand static security filesThe following files are installed with Flash Media Server
to therootinstall/phds/static folder. Do
not replace or modify these files.
Policy fileFlash Media Server installs
with the policy file rootinstall/phds/static/phds_24hr_policy.pol.
The policy is set as:
anonymous; not use license chaining; 24 hours limited license caching; and binding to the Shared Domain is permitted.
This
policy file lets clients start playing content within 24 hours from
when the server generated the DRM metadata. Users can continue watching
the content until the end, even if that time is beyond the 24 hour
window. The 24 hour window starts when the server generates the
DRM metadata and stores it in a cache. The <UpdateInterval> parameter
in the Application.xml file determines the frequency at which the
server generates DRM metadata. The default value is 60 minutes.
License server certificateAn Adobe-issued
DER-encoded license server certificate. The license server certificate
specifies the private key used to sign the license.
Transport certificateAn Adobe-issued
DER-encoded X.509 transport certificate file. The transport certificate
file is used when the client communicates with a server (for example, an
authentication server). This feature is not supported in Flash Media
Server 4.5.1 but the certificate is still required.
Packager credentialAn Adobe-issued packager
server credential (a certificate and its associated key) PFX file.
The server uses this file to apply a signature to the metadata while encrypting
content files.
|
|
|