Skip navigation
j_1234
j_1234
Currently Being Moderated

PHDS, encryption weirdness?

Aug 15, 2012 8:34 AM

Tags: #4.5 #fmis #phds #4.5.2

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

637 Views   4 Replies   Latest reply: j_1234, Aug 31, 2012 1:21 AM
 
Replies
  • mohit-sharma
    Currently Being Moderated
    1. mohit-sharma,
    Aug 27, 2012 9:47 PM   in reply to j_1234
    Report

    Hi J_1234,

     

    Can you give us your httpd conf ?

     

    Thank you.

     
    |
    Mark as:
  • j_1234
    Currently Being Moderated
    2. j_1234,
    Aug 28, 2012 1:06 AM   in reply to mohit-sharma
    Report

    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

     
    |
    Mark as:
  • mohit-sharma
    Currently Being Moderated
    3. mohit-sharma,
    Aug 31, 2012 12:11 AM   in reply to j_1234
    Report

    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

     
    |
    Mark as:
  • j_1234
    Currently Being Moderated
    4. j_1234,
    Aug 31, 2012 1:21 AM   in reply to mohit-sharma
    Report

    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!

     
    |
    Mark as:
Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points