Roku Developer Program

[bbefilms]

I'm still trying to figure out secure mechanism for Roku connections. Does the Roku Player have a public key so that I can be sure that connections to my video server are from a Roku player and not another agent? It's apparent from this site that Netflix access is supported by a strong verification and encryption system. It's also evident from the same site that folks are packet sniffing Roku players to determine access. It's not clear to me at all that the paradigms documented in the SDK provide any kind of verification that server access is by the Roku player or any other agent, which could be spoofed by packet-sniffing URL's. Please could one of the devs indicate what I'm missing on this (I'm currently editing two features as well as trying to set up my Roku channel and running on coffee and a few hours sleep a night, so it's quite possible that I'm missing something).
Thanks, Greg.

[supersecretuser]

There really isn't anything. You can use SSL for the xml transfers, but on media playback you have to trickery server side (like single use tokens).

[bcl]

I haven't looked too closely at the registration process, so this is a WAG. But what I would do would be:

1. Use SSL for all connections
2. When the user enters the registration string on the server side pass a token back to the device (SHA1 hash of something)
3. On the Roku store this token in the registry
4. When playing pass this token to the server. This is over SSL so immune to sniffing.


Brian

[bbefilms]

That's unfortunate in the sense that a public key system in the Roku would save a lot of trouble and potentially major performance hits with SSL. My guess is that public/private key encryption exists in the Roku player but that it's not available to us. I'm using a fast HTTP server and my SSL is also fast, but I'm 99% sure that streaming HD video via SSL would be problematic.

[RokuMarkn]

Amazon videos are streamed over SSL, so it's definitely possible. SSL does do decryption which takes some time, but any DRM involves decryption so it's just a question of where the decryption is done, in the SSL protocol or somewhere else.

--Mark

[RokuKevin]

The SDK provides all the support necessary to protect your content, and large established content providers have trusted the security methods the SDK provides. However, the success of the content protection requires a proper implementation by the developer, and Roku is not responsible or liable for any losses resulting from use of the SDK.

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 a URL that contains video content. Finally, since time expiring URLs are used, it is not possible to exploit content URLs in a broad way.

Please read Section 4.25 of the Component Reference. It will explain the SDK support provided to protect your feeds using mutual TLS authentication. Section 4.5 will explain how to use SSL with the ifHttpAgent interface to play media content delivered over https.

--Kevin.

[bbefilms]

Thanks guys, I'll read further.

[bcl]

FYI - I've been reading the Amazon CloudFront docs, and they provide signed URLs with enforced timeouts, but they don't (yet) provide SSL access to it. Alot of people have been asking for it, so I would expect it to show up as a new feature sometime soon.

[bbefilms]

OK, I've has a chance to look further at the docs and the information on SSL is fairly terse. It's 2:00am and I'm not making much headway; please could a Roku dev (or anyone else) correct me in the following assertions, which I'm sure will help others like myself to be more able to rapidly develop apps for the Roku platform:

In order to support https url's (e.g. SSL connections), either roUrlTransfer or ifHttpTransport objects need to first make a call to set the location of the certificates file, then make a call to add the special header so that we get the developer ID on the server (which allows us to confirm the request source) and then initialize the client certificates. The PEM format file pointed to in the method call "SetCertificatesFile" should contain the certificate authority cert that signed the cert on the HTTPS server. So therefore, some example partial code is:

obj = CreateObject("roAssociativeArray")
obj.Http = CreateURLTransferObject(url)
obj.Http.SetCertificatesFile("pkg:/certs/PositiveSSLCA.pem")
obj.Http.AddHeader("X-Roku-Reserved-Dev-Id", "")
obj.Http.InitClientCertificates()

...and this is all that's required to pass URLs that start with HTTPS to the URLTransport object? SSL URLs passed in this way in my app are crashing the Roku player. Am I missing something about which certs are required?
Many thanks for any help
Greg

[bbefilms]

OK, I'll answer my own question after spending much time figuring it out, it was a certificate thing. Would suggest to anyone else who has similar probs to get ssl access running with the curl unix program, since they're using the curl library to perform url access.