Roku Developer Program

Join our online forum to talk to Roku developers and fellow channel creators. Ask questions, share tips with the community, and find helpful resources.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
fortscan
Visitor

Piracy protection for private channels (SDK DRM?)

Is DRM supported for private channels developped through SDK?

Based on different posts of this forum, it seems like DRM support was apparently included as a possibility but then the developers explained it wouldn't work.

If DRM is not possible, do you have any alternative other than expiring URLs for the mp4 videos or SSL streams?

Thank you.
0 Kudos
17 REPLIES 17
RokuKevin
Visitor

Re: Piracy protection for private channels (SDK DRM?)

We do not have generic Windows DRM support at this time.

However, Hollywood studios have approved some of our partners to distribute titles using mutual SSL authentication on the feeds and randomized time expiring ssl urls on the video. This technique is explained in the Component Reference.

You can also use AES 128 bit encryption with HLS. This technique is documented in the HLS specification.

--Kevin
0 Kudos
fortscan
Visitor

Re: Piracy protection for private channels (SDK DRM?)

We have been testing the mutual SSL authentication, based on the reference examples provided in the SDK.

Regarding time expiring URLs, we do have this feature available for our online video distribution, using CloudFront "private content" feature of Amazon S3, but we haven't been able to find a good way of integrating it to Roku. When someone purchases a video online (web browser), it's easy for the billing and authorization system to inmediately send a response that includes the random, time-expiring URL for the client to access. Suppose we wanted to use the same billing and authorization platform but based on Roku as STB instead of a regular browser. Would there be any way for our servers to provide the random URL only for the specific STB of the client who purchased the movie?

In other words, is it possible to have some level of interaction between the Roku STB and our CDN? Perhaps an example of how to integrate time-expiring URLs with Roku would be very useful.

Thank you as always for your excellent feedback, it is highly appreciated.
0 Kudos
kbenson
Visitor

Re: Piracy protection for private channels (SDK DRM?)

The registration examples in the SDK show how to register a Roku to specific online service account. You could use this to register the Roku unit to a specific account with your service, and serve only the content that account is authorized to access.
-- GandK Labs
Check out Reversi! in the channel store!
0 Kudos
RokuKevin
Visitor

Re: Piracy protection for private channels (SDK DRM?)

Yes. Generally the way you would do this is to link the box to a user account. The user account would have access to their own "library" of purchased/rented titles on your web server. Your "library" feeds will include only titles that user is authorized to play and these feeds will contain the server generated randomized time-expiring urls to the actual video content. If you've found an Amazon CloudFront web service that already does this, I think it would be a valuable find for many other developers on this forum.

Some content providers will protect their media content with randomized, time-expiring URLs on content distribution networks (CDNs). When the Roku player requests playback of a particular URL, the web-services API returns the URL to access the media file over the SSL connection. This is the HTTPS URL used to stream the video content from the CDN. Since access to the URL is protected by the SSL connection to the content servers, it is not possible for someone to determine the URL for the content by analyzing network traffic. Since the URL is randomized, it is not possible for someone to guess the URL that contains video content. Finally, since time expiring URLs are used, it is not possible to exploit content URLs in a broad way.

Legal Disclaimer:
The success of the channel's security model requires a proper implementation by the developer, and Roku is not responsible or liable for any losses resulting from use of the Roku SDK or any information posted on these forums.

--Kevin
0 Kudos
fortscan
Visitor

Re: Piracy protection for private channels (SDK DRM?)

On Section 4.8 of the DesignGuidelines it says:
"To learn more about linking, refer to “Typical Application Linking Flow” at the beginning or this document or the technical document Content Data and Hosting available at: developer.roku.com"

Where can we find the "Content Data and Hosting" document? (developer.roku.com is not working)

It seems like you prefer to suggest the "rendezvous" registration scheme with the on-screen code that the user has to enter at the provider's website instead of the username/password scheme. Is this for security reasons? We believe that, from the user's perspective, not having to interact with his PC, and doing all the registration process directly via the Roku, could be an advantage. Are there any reference examples or some documentation regarding username/password registration scheme?

Thank you.
0 Kudos
mainmanc
Visitor

Re: Piracy protection for private channels (SDK DRM?)

Hi,

Does your billing and authorization system have any type of API that might be accessed remotely?

It's possible that you could do what you want by adding an application layer in-between the Roku and your account software.

Marking the account, and moving the url data to the Roku should be trivial.

Cheers.
0 Kudos
fortscan
Visitor

Re: Piracy protection for private channels (SDK DRM?)

mainmanc: that seems like an interesting approach. Our billing system could easily interact with a remote host/system such as the Roku, but it's still not clear for us how the DVP itself would authenticate the client, unless using standard username/password scheme (vs. rendezvous with on-screen token).

Since RokuKevin mentioned it, we are using different S3 PHP tools to automatically generate signed URLs that expire after a defined time or after a defined number of clicks. CloudFront is used as the CDN that actually connects to S3 where the videos are stored.

For instance (requires importing hmac.php):

require_once('hmac.php');
/*
* sign the URL, given original URL and secret key
*/
function signUrl($unsignedUrl, $secretKey){
$parsedUrl = parse_url($unsignedUrl);

parse_str($parsedUrl["query"],$output);
ksort($output,SORT_STRING);

$first = true;
$sortedQuery="";
foreach ($output as $key => $value) {
if ($first) {
$first = false;
} else {
$sortedQuery .= "&";
}
$hmac_data .= $key . $value;
$sortedQuery .= $key . "=" . urlencode($value);
}
$strToSign = $parsedUrl["path"]."?".$sortedQuery;
//echo "<br> StrToSign: ".$strToSign;
error_log("wine: str to sign = ".$strToSign."\n", 3, "c:/php.out");
//get HMAC signature
$hmac = new Crypt_HMAC($secretKey,"sha1");
$hmac_digest = $hmac->hash(trim($strToSign));
$binary_hmac = pack("H40",$hmac_digest);
$base64_hmac = base64_encode($binary_hmac);

return $unsignedUrl."&awsSignature=".urlencode($base64_hmac);
}


This allows to create expiring links inside each user private section, that they can easily access after logging-in. The process is as follows:

* User purchases a video/movie and pays for it through our distribution channel
* Payment is reported to our database and user gets authorization for x number of videos/movies
* User logs in to his private section (that's how we identify it), browses the entire catalog, and when he selects a video/movie, the system generates a 24hr expiring link to that movie, associated with his ID, and places that link into a private folder
* The user's STB retrieves that link by using authenticated "wget" from our servers, and associates the link with a variable that is later used by the MPEG4 internal player as target file

Does anyone have any suggestion about how a similar procedure could be coded for Roku DVP? Is there a way to first authenticate the user, then make Roku download an expiring link, and associate that link to a variable that can be later user as the simpleVideoplayer target mp4 file?

Thank you.
0 Kudos
kbenson
Visitor

Re: Piracy protection for private channels (SDK DRM?)

The Roku contains a full script environment in BrightScript, which allows for local storage in a temporary file system (persistent for runtime of app), limited storage into the registry (persistent for install of app, very small storage space) and storage in the application package itself (total application limited to 500K of compressed code + files).

I see no reason why an application couldn't prompt for account info when first run, and use this to authenticate to your system, and store the credentials in the registry. From that point, the application should be able to automatically associate to the account when run using the registry info.

Since you have access to a full scripting environment, and can perform GET and POST requests as needed, I see no reason why you couldn't easily retrieve a list of videos and associated info (such as image, cost, etc.) to display, similar to how Netflix does. You could have a separate "queue" to view the videos the account has access to currently, which would need to be supported by a method on your site to list them. At the point the video becomes unavailable, as long as your site isn't listing them when the list of accessible videos is requested, they should no longer show up on the Roku.

Think of it this way, if you had to re-write the front-end of your site in a different programming language, but wanted to leverage the same back-end you already have, you might code the front end to just make requests for the metadata from the back-end and sort and display it accordingly. That is directly analogous to how you would accomplish this with the Roku, since the Roku is really just a different front-end for you.
-- GandK Labs
Check out Reversi! in the channel store!
0 Kudos
RokuKevin
Visitor

Re: Piracy protection for private channels (SDK DRM?)

Although it is possible to store username/password credentials encrypted in the registry, we expect that most channels will want to provide the Rendezvous linking mechanism for associating the box with an account on your site.

It is painful to enter credentials on the on-screen keyboard, and can be a security concern where other users can easily see the password that is entered. Although it requires a computer, rendezvous linking solves these problems.

--Kevin
0 Kudos