Copy link to clipboard
Copied
General Questions
Using Adobe(Flash) Media Server 4.5+ , you can protect your live and on-demand content before delivering client using DRM based technology. Such streams can be be played back on Flash Player ,AIR and over HTTP. When played back on iOS over HTTP, use client built with Adobe Access iOS SDK. When Adobe Media Server packages the content, it generates the license and embeds it into the DRM metadata of the content stream. This feature is called Protected HTTP Dynamic Streaming (PHDS). In addition to encrypting content, PHDS also supports SWF verification for HTTP Dynamic Streaming. Same feature over Apple’s HTTP Live streaming is known as PHLS and over RTMP is known as PRTMP.
PHDS/PRTMP/PHLS provide some additional non-DRM protection features over and above the native protection/encryption schemes without the need of a license server. They are implemented using same protocol specification (for communication between client and server) as AAXS and hence may appear as a lightweight version of Adobe Access.
DRM metadata is a binary data that transport the policy, CEK (Key used to encrypt data), license or license server URL. It is securely interpreted by Adobe Access runtime with Flash Player. CEK inside DRM metadata is transported as encrypted.
A license is a data structure that contains an encrypted key used to decrypt content associated with a policy. Using a policy as a reference, the license defines the rights available to the consumer who downloads content. In order to view content, the consumer must obtain a license.
License is embedded inside DRM metadata in case of PHDS/PHLS. In case of PHDS/PHLS, license is generated by packager when the consumer requests playlist or DRM metadata. PHDS/PHLS involve embedding domain bound licenses (not device bound) with support for "player binding" policy reinforcement. The "device binding" policy reinforcement can only be done at license server (in case of Adobe Access).
License server generates the license when the consumer requests content, and is bound to the consumer’s computer. The License Server may be integrated into the distributor's or service provider's billing and authentication systems, and may contain business logic to verify that the consumer requesting protected content is authorized to view the content. If the user is authorized to access the content, the License Server issues a license allowing the runtime client to decrypt and playback content based on the policy and rights associated with the consumer's account.
A policy is a container for the usage rules that determine how consumers can use protected content. Policies are defined independently of the content being protected. A policy does not enforce rights until it is bound to the content through the license. A policy lists the set of usage rules, meaning the permissions or “rights” that consumers have to the content they acquire. For example, content owners may create a policy that ensures that protected content is only accessible by consumers for a specific period of time. This policy is then applied to all the content for which the content owner wants to enforce this restriction.
To change policy, one needs to configure the packaging server (AMS) for one of the defined policy. Read AMS documentation for available policies. One needs to invalidate the DRM-metadata in cache or for already playing streams (by initiating replay) to take new policies to take effect.
You can’t.
These certificates license the stream to be playable on different set of devices/systems. As an alternative to binding a license to a specific device, Shared Domain Certificates binds licenses to a domain. Read Domain Registration in Using the Flash Access Server for Protecting Content. AMS comes with 3 shared domain certificates.
Yes. Once the content is packaged, it remains protected at all times, and portions of it are only decrypted at the time of playback and in accordance with the usage rules. Because the content is packaged with usage rules and licensing information, protection always travels with the content. If unlicensed consumers attempt to play the content, the policy embedded in the content redirects them so they can acquire a valid license for the content.
Certificate expiry of shared domain certificates is not checked.
Output protection controls can be used to engage protection schemes such as HDCP, CGMS-A or Rovi (formerly Macrovision) ACP. This can help protect content output over digital (for example, HDMI, DVI, and UDI) and analog (for example, S-Video, and Component Video) outputs. There are two types of output protection, analog and digital, and they correspond to the type of external connector a user is attaching a display to. Ability to turn on or off Output Protection is determined by what is exposed to Adobe DRM by the OS. AMS has DRM policies for HDS that can select to have OP turned on in one of three ways:
a. Required b. best available c. Not Required
OP is only needed if content is displayed on a secondary display (not the internal display). OP if set to “Required” and device is not able to turn on OP for any external display that is plugged in, content playback is not allowed. OP if set to “Best Available”, OP is tried to be turned on for all external displays if possible, but content is allowed to playback even if it is not available.
Specifies whether all frames, or only a subset of frames should be encrypted. There are three levels of encryption: low, medium and high. Reducing the encryption level may decrease CPU overhead on lower end machines.
One must use Key Rotation feature. When key rotation is enabled, the key used to encrypt the content can be changed so that the key is only used to encrypt a portion of the content.
Individual fragments are encrypted using AES-128 algorithm.
PHDS is simply a way to take a content key (CEK) and protect it with an RSA public key. The only entity that knows the private key is the Adobe Access clients. For middle man to change the content, they need to be a licensee of Access.
Adobe Access requires license server, which provides additional external security in delivering the key by potentially binding it to individual client and ensuring it to be decipherable by authenticated client only. License server can also overwrite the policies packager's embedded policies.
DRM Policy
Policies are packaged inside the license and are enforced by the Adobe Access run-time in Flash Player on client side.
This is relative to the time of DRM metadata packaging time at the origin. If a client requested the DRM metadata at 1 Jan 2012 12:00:00, and was served from the origin, then after 2 Jan 2012 12:00:00, it will not be valid. Even if for further clients DRM was served from the cache, it will no longer be valid after 2 Jan 2012 12:00:00.
Adobe Access Run-time at client side reads the policies and enforces the expiration. This information is within the DRM metadata in form of either end-date-time or relative time from acquisition.
Only at the start of playback expiration is checked. So within same client session, it will play the full content length. For above example, it will play till 2 Jan 18:00:00 (if client is not restarted). However, this is valid only if DRM is not updated with new policies in between the content playback and forced by the server on the client by protocol. Check your AMS server configuration for DRM update strategy.
This new client will be able to playback full content. Policy expiration is checked only at the start of the client play. DRM metadata must not be expired at time of client play start.
No. Since DRM was served from cache which was created at 1 Jan 12:00:00, it will be expired at 2 Jan 12:00:00. So client playback won’t start.
Only DRM metadata needs to be regenerated. Fragments needs the regeneration only if CEK (common-key or content Id) has been changed for the stream at origin.
Think again, do you actually need to use “unlimited” expiration policy. If you are sure it’s not, set TTL for the DRM metadata so that caching servers sends the request back to origin after that much time.
Configuring PHDS/PHLS on Adobe Media Server
In Adobe Media Server, this is not supported in Standard version. For other versions, it is fully supported.
Content ID uniquely identifies the stream. This is used to generate unique CEK for different streams. By default this as per stream name or stream path.
No. This will cause different CEK to be generated for different renditions and thus can produce non-smooth switching experience.
It depends upon the common-key and content id. One may define these parameters at server or application or event level in case of Live. In case of VOD, these can be configured at server or ABR set level.
You can do it using the scramble tool. It can be found inside <AMS installation>/tools folder. Read more about how to use it here: http://help.adobe.com/en_US/adobemediaserver/configadmin/WS39626d08e1cf8a41-5a4bd5e8131b50aa039-8000...
Yes.
A set of streams is defined by the folder path of the content on the disk You need to either configure different content-id or common-key for different set of streams. By default, AMS ensures different content id for different path of VOD contents on the disk. To configure, different common-key for different set (path) of VOD content:-
1. Define (HDS/HLS)EncryptionScope as content in Apache's conf.
2. Define jit.conf at content path. In this case, only encryption configurations defined in jit.conf are used to encrypt the content.
In this case, server level encryption configurations (in httpd.conf) are completely discarded. In case of VOD, one may enable or disable encryption and set configuration properties per VOD set (path) level. This can be set inside corresponding jit.conf. In case of Live, one may define multiple applications and enable or disable encryption along with required configurations inside application.xml corresponding to different applications. Alternatively, application.xml can allow event.xml to enable or disable encryption and define encryption properties specific to event inside event.xml. In later, case Application.xml's encryption properties are completely ignored.
Think again, do you actually need to enable key rotation feature instead of manually changing the key file. However, this is not recommended. Even if you are doing it, ensure that caching directives for DRM metadata and fragments are correctly set to instruct the proxy caches to re-request your content after key has been changed. Also ensure, on packaging AMS server, files have been touched for instructing AMS to not to return 304.
You can choose one of the predefined policies and define them in application.xml. You need to set the encryption scope as “content” and define encryption configurations in application.xml. Certificates are not meant to be changed for PHDS/PHLS unless provided by the Adobe. In case of VOD, you can define different policies for different content by defining encryption configurations in corresponding jit.conf.
Enable swf verification or white list feature in PHDS or PHLS respectively.
All client share same encryption key, so gets same fragments after encryption. To configure different encryption key (or any other protection parameter) for different set of clients, define multiple location tags in httpd.conf. For each set of clients, define different configurations inside different location tags. In this case, URLs for different set of clients will differ in location tag value.
(P)HDS/(P)HLS content is packaged and delivered through Apache modules shipped with AMS. In case of Live, content needs to be packaged at origin only and so should be delivered through Apache server at origin only. In this case, scalability can be achieved by third party HTTP cache/proxy servers in front of AMS origin.
DRM/content Cache
In case you want to change the allowed applications to playback the stream or extend the policy expiration time.
DRM is just-in-time created with every request of the f4m file hitting the origin. However, packager (AMS) may return 304 if file is not changed and if-modified-since header is set in the request.
DRM is just-in-time created with every request of it hitting the origin. However, packager (AMS) may return 304 if allowed-apps list is not changed in the configurations and if-modified-since header is set in the request.
Ensure you configure the TTL for the DRM requests or F4M requests proactively in such a way to indicate the life expectancy of the DRM metadata.
There is no need to invalidate the fragment cache unless CEK for the content has been update. It is not recommended to update CEK manually in between. Either use key rotation feature or change the stream path for the purpose.
In this case, both DRM and fragments gets changed. So it is recommended to revise the content URL on the client application, so that caching servers don’t get a hit. In this case, within Apache origin’s configuration, you may rewrite the URL to map to actual content URL.
Configuring PRTMP on AMS
pRTMP encrypts the content and embeds policies within the content. On other hand, RTMPe secures the channel.
Yes. But there is no implicit advantage. It is better to use just one; otherwise it may have extra overhead on the client side to decrypt the content twice.
To allow or disallow future client application to playback the content.
No, it will affect only the new stream-playback requests.
Not necessarily. However, it is not recommended to use different pRTMP settings in different applications, if they are planned to stream same content.
No you can't change policy. 24 hours policy file is used internally.
No, AMS supports pRTMP only for VOD content. In case, you have strong need to support it for Live, please contact Adobe.
Please refer http://www.adobe.com/devnet/adobe-media-server/articles/swf-verification-protected-http-dynamic-stre...