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.
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
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.
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.
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
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.
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.
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:
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.
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.
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
Thanks Kevin. Using the on-screen keyboard is obviously not easy for the end user.
We have reviewed all SDK related documentation but we still couldn’t find a complete explanation, perhaps with a couple examples, that defines how the rendezvous linking works. Could you perhaps point us to some specific part of the documentation, or a basic flowchart of how it operates?
Where can we find the “Content Data and Hosting” document? (developer.roku.com is not working)
Is the token number retrieved from a variable internally stored on the DVP, such as serial/mac, or is it retrieved remotely from a server? If this is generated remotely, and user has to enter the token number he sees at the screen while being logged into the membership site (on his PC), this would confirm that only he is able to know that number. But how does this imply that every request coming from his DVP will be treated as “authenticated” by our servers? In other words, what kind of individualization process is added (perhaps encrypted headers?) to each request coming from a registered DVP to validate it at the CDN/servers level?
fortscan,
There is no “Content Data and Hosting” document in the SDK… I believe you are looking for the “RokuDvp-DeviceRegistrationAndLinking.pdf” document. That doc will explain the linking process in detail.
There is also a “register” sample app that shows the brightscript implementation of rendezvous linking. Note that there is also a server side implementation that will be specific to your site. Your server will generate the rendezvous number the user will enter on your server. It has nothing to do with the serial number or mac addr of the box. Your server will also generate a “Device Service Token” (DST) that you Roku channel will store in the registry. It is this DST that is used to authenticate the box and associate an account when the user gets customized feeds from your site.
–Kevin
I wrote a rendezvous type linking page that is built on Google App Engine which have very generous free limits. All API keys and authentication tokens are stored locally on the Roku box and all this really does is handle the handshaking between the Roku box and the service.
You can see the source here:
http://bitbucket.org/chrishoffman/appen … ulink/src/
Chris
Thanks Kevin for pointing out this Post.
how would we use this in a php environment and connect soley to our Mysql DB? not using google app engine or oauth
Python is as foreign as Brightscript is to me 
Thanks to everyone who is contributing with ideas regarding this post.
We will install and try the linking page built on Google App which seems a great reference from hoffmcs.
We are currently deploying a global VoD service in a region outside the US, where Netflix/Amazon don’t operate. Due to the security requirements from each of the studios and content aggregators we work with, we are trying to improve DRM scheme for the devices we will be supporting for streaming (set-top-boxes). Although it seems like we won’t be able to use propietary DRM when streaming to Roku DVPs, we still want to incorporate it as a supported device due to its economical price, which could make the whole service more attractive, globalizing its adoption.
Besides SSL mutual authentication and random, expiring links for the content at the CDN, does anyone have any suggestion/idea about additional security features compatible with the Roku SDK for securing the content?
Thank you.
We have a membership service where members have unlimited access to videos (similar to Napster.com for music, or Hulu Plus). Videos are stored on Level 3 CDN, and can be authentication via a token (time expiring unique code generated on our servers based on authentication).
We will be creating a Private Channel, which will allow members of the website to view the same content on Roku.
We need help understanding how the registration and authentication is performed. Once a user links their Roku via rendezvous, they will have access. How do we revoke access once the membership is expired?
The members table stores username/password/membership status (1=active, 0=expired).
So should we also store the Device Service Token in this table to associate the account with a Roku box?
If a member does not have roku box id store in our db, or his status is expired, an XML file with the list of videos would not be generated.
How would I notify the user on the Roku box, that his membership has expired?
I would want the steps to be like this:
What happens if the Roku channel is left open while the membership expires? At this point, since the channel already checked for membership status once, it would still allow access to the channel, but my XML files with content and authentication tokens would return empty. How can I in some way poll for the status, upon status change , the viewer should be presented with the same dialog box in step 4.
Finally, it would be very useful to have a complete example in the SDK that mimincs Hulu Plus or Netflix’s channels to see how they perform these authentication steps.
Denizb,
How do we revoke access once the membership is expired?
You could remove the DST from the “valid DST” column in your members table on your website.
So should we also store the Device Service Token in this table to associate the account with a Roku box?
Yes. That would be a good place.
How would I notify the user on the Roku box, that his membership has expired?
You may want to have a section of your channel accessible to “members only”. If they don’t have a valid account they won’t be able to access it. You could message the user to this effect and show a linking screen anytime this section is not accessible. (Try Your Video Library in the Amazon channel as an example).
What happens if the Roku channel is left open while the membership expires?
You could validate the DST on every request if desired… Or any timeout period you desire.
Finally, it would be very useful to have a complete example in the SDK that mimincs Hulu Plus or Netflix’s channels to see how they perform these authentication steps.
Please see the “register” example in the SDK. There is also the Device Linking and Registration guide in the SDK.
–Kevin
You could validate the DST on every request if desired.
How would one do this, is there an equivalent way to put the DST in the header as is done with “x-roku-reserved-dev-id” in the mutual SSL setup?
(This is what i have for that)
screen.Addheader("x-roku-reserved-dev-id","")
screen.SetCertificatesFile("pkg:/source/cacert.pem")
screen.InitClientCertificates()
and I’ve tried
screen.Addheader("RegToken","XYZ")
as well as various other things but the RegToken wasn’t in the headers even though ‘x-roku-reserved-dev-id’ is-
OK I figured it out; in the videoPlayer there is a ‘appDetailScreen.brs’ and ‘appVideoScreen.brs’ - these settings appear in both and I was only putting it in one (the wrong one). pardon the interruption 
