Skip to main content
A
Anonymous
August 15, 2012
Question

PHDS, encryption weirdness?

  • August 15, 2012
  • 2 replies
  • 1380 views

Hi,

in an earlier post of mine (http://forums.adobe.com/message/4364896) it was stated that the content encryption key was derived from the common-key and the Content ID.

Now, I've been experimenting some with this, inserting a proxy doing some filename translations between the client and the actual server, any requests containing "999x222Seg*" gets rewritten to "999y222Seg*", i.e. a different filename. Both "999x222.mp4" and "999y222.mp4" exists on the server.

Client requests /hds-vod/999x222.mp4.f4m, proxy forwards exactly the same. Server sees 999x222_1400.mp4.f4m as filename, and the drmAdditionalHeader is set to drmContentId="999x222.mp4" as expected

Now, the client requests /hds-vod/999x222.mp4Seg1-Frag1 as expected. This is however translated in the proxy, and the server will see a request for /hds-vod/999y222.mp4Seg1-Frag1, i.e. NOT the same filename as the manifest was issued for, and thus not the same content ID (?), which would mean another content encryption key would be used.. However, the client is still able to play the video!


From my understanding, that should not be possible? 999x222.mp4 and 999y222.mp4 are two different files, two different content IDs, and should thus have two different content encryption keys. The key from the initial manifest should only be able to decrypt the fragments from 999x222, not 999y222?

FMIS 4.5.2 is used, and the default /hds-vod PHDS config is used, with protection specifics as follows:


EncryptionScope server

ProtectionScheme phds

PHDSCommonKeyFile ../phds/common-key.bin

PHDSPlaybackExpiration "24Hours"

PHDSOutputProtection None

PHDSVideoEncryptionLevel 2

Can anyone shed some light on this?


Thank you

This topic has been closed for replies.

2 replies

mohit-sharma
mohit-sharma
Participant
August 31, 2012

Hi,

By default, FMS uses non-unique content-id if protection-scheme is set. It takes path of the file as its content-id. Therefore, in your case, it takes same content-id for both files as they are kept in same folder. This was introduced so that same content-id encryption can be used for multi-bitrate stream where all files with different bit rate are kept in same folder.

If you want to use unique content-id for each file, please include this tag in ur httpd.conf file.

FlashAccessUseUniqueContentID true

By default, this is set as false.

Also, If you want to specify some content-id (for example: 'my-content-id') to be used as content-id for all the files, please use this tag. Also, donot set FlashAccessUseUniqueContentID to true.

setFlashAccessContentID my-content-id

A
Anonymous
August 31, 2012

Hi,

aha, that explains it. Setting FlashAccessUseUniqueContentID to true did the trick.

The m4f manifest for one single mp4 file has an drmAdditionalHeader with drmContentId="999x222_1800.mp4", i.e. the full filename, not including the path. This is the same regardless of the UseUniqueID setting. Bug?

Does the server or client benifit in any way of using a shared content ID for all the bitrates? The encryption metadata is sent in every m4f manifest (one per bitrate) anyway, correct? Since the drmContentId is different for all the files, I'd expect that the client has to decode the full drmAdditionalHeader element even though it's using the same key?

From what I've found in the docs, there is no mentioning of any of those two options, nor the fact that the same key is used for all files in a directory.

Are there any more undocumented quirks/features like this?

Thank you!

mohit-sharma
mohit-sharma
Participant
August 28, 2012

Hi J_1234,

Can you give us your httpd conf ?

Thank you.

A
Anonymous
August 28, 2012

Hi,

the default Apache config is used, the only changes made are in the hds-vod section, which reads:

<Location /hds-vod>

    HttpStreamingJITPEnabled true

    HttpStreamingContentPath "../webroot/vod"

    HttpStreamingJITConfAllowed true

    JitFmsDirPath ".."

    Options -Indexes FollowSymLinks

 

        EncryptionScope server

        ProtectionScheme phds

        PHDSCommonKeyFile ../phds/common-key.bin

        PHDSPlaybackExpiration "24Hours"

        PHDSOutputProtection None

        PHDSVideoEncryptionLevel 2

</Location>

One more thing, which might or might not make a difference. 999x222.mp4 was one file, and 999y222.mp4 was a symlink to the first file, rather than a truly standalone file.

Thank you

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices