Netflix on Android(blog.netflix.com)
blog.netflix.com
Netflix on Android
http://blog.netflix.com/2010/11/netflix-on-android.html
40 comments
The problem comes down to key-hiding. You can encrypt it all you want but if the attacker can extract the key from the software the game is over.
Working with the mobile phone providers, you can embed the root key in hardware. This makes it more difficult to extract. Straight software solutions exist, but are typically provided 3rd parties or by the OS vendors themselves. The software solutions are obviously more convenient, for the reasons you've alluded to.
Netflix gets to make lots of money exactly because they do the hard work of working with the backward-facing industries.
Working with the mobile phone providers, you can embed the root key in hardware. This makes it more difficult to extract. Straight software solutions exist, but are typically provided 3rd parties or by the OS vendors themselves. The software solutions are obviously more convenient, for the reasons you've alluded to.
Netflix gets to make lots of money exactly because they do the hard work of working with the backward-facing industries.
But why is Android any worse than, say, Windows XP in this respect?
The encryption/decryption libraries exist on Windows. For example, http://en.wikipedia.org/wiki/Windows_Media_DRM
I think that Netflix also doesn't want to be in the business of building the full secured/DRM code stack on all these platforms themselves. They'd rather leverage. And for whatever reasons I believe they are/were a Microsoft video encoding shop on the backend, which can limit their choices (e.g. they won't use Adobe Access on Flash, which is not universal either).
I direct you to the nutjob123 conversation tree on this very topic, starting here: http://news.ycombinator.com/item?id=1901128
Could someone who understands the technical issues explain the details better? While perfect security is of course impossible, I would think that a 'secure' flash player could basically be grabbed off-the-shelf. And I haven't really thought about it, but I don't understand why a native app would be that hard. I presume the goal is just to make it difficult to record the movies to disk?
There are certain specs that anyone implementing a video streaming/content delivery service must comply with. The studios mandate that certain specs be followed, and an engineer has to sign off that they've implemented the DRM spec correctly. For an example, look at DTCP-IP (http://www.dtcp.com/)
The specs mandate usage of certain types of encryption algorithms, key lengths, key expirations, etc. All the data that is sent over the wire is encrypted, so that no one using a packet sniffer can trivially obtain the unencrypted video. Thus, from the point of view of the attacker, the problem becomes extracting the encryption keys from the software and using that to decrypt the sniffed traffic.
Every device/software module ends up having a some root key that must be seriously obfuscated, because that key provides the security for the entire system. It must be embedded in the software or hardware. If its in hardware the problem is easier, because it cannot be disassembled and discovered as readily. In software, the problem is more challenging. Some form of White-Box Cryptography has to be used.
So, a secure flash player or a native app is only the first step in the solution. The whole key management system has to be built or provided by a 3rd party library. Google doesn't have such a library built in to Android. After you have the library, all kinds of nasty tricks have to be used on the library itself. Generally, the goal is to prevent debugging and code modification. The tactics used are very similar to what malware authors use to protect their malware from reverse engineering.
The specs mandate usage of certain types of encryption algorithms, key lengths, key expirations, etc. All the data that is sent over the wire is encrypted, so that no one using a packet sniffer can trivially obtain the unencrypted video. Thus, from the point of view of the attacker, the problem becomes extracting the encryption keys from the software and using that to decrypt the sniffed traffic.
Every device/software module ends up having a some root key that must be seriously obfuscated, because that key provides the security for the entire system. It must be embedded in the software or hardware. If its in hardware the problem is easier, because it cannot be disassembled and discovered as readily. In software, the problem is more challenging. Some form of White-Box Cryptography has to be used.
So, a secure flash player or a native app is only the first step in the solution. The whole key management system has to be built or provided by a 3rd party library. Google doesn't have such a library built in to Android. After you have the library, all kinds of nasty tricks have to be used on the library itself. Generally, the goal is to prevent debugging and code modification. The tactics used are very similar to what malware authors use to protect their malware from reverse engineering.
Are the requirements for Hulu different than those for Netflix? Or is the Hulu solution flash plus a hardened native library of the sort you describe. I guess my confusion is why Netflix couldn't do the same.
My instinct is that key exchange is tricky but a solved problem, that the encryption itself is trivial once you have the keys, that true security is impossible without hardware support (TPM), that analog holes will always exist, and that the current hard part is preventing someone from swiping your digital video stream on its way to the screen. Does this seem accurate?
My instinct is that key exchange is tricky but a solved problem, that the encryption itself is trivial once you have the keys, that true security is impossible without hardware support (TPM), that analog holes will always exist, and that the current hard part is preventing someone from swiping your digital video stream on its way to the screen. Does this seem accurate?
Its all based on whose content you are streaming, and what specifications they mandate for access to their content. Generally, I'd imagine both Hulu and Netflix are subject to the same specs, but I'm not familiar with the specifics.
Your instinct is close.
key exchange is tricky but a solved problem.
True
encryption itself is trivial once you have the keys
Encryption/decryption itself is trivial in hardware. In software, its wholly non-trivial to the point that it merits investigation by the academic community.
analog holes will always exist
and
the current hard part is preventing someone from swiping your digital video stream on its way to the screen
Analog holes do exist, but its still easier to extract keys from software and decrypt wireshark dumps. Especially because this can allow you to fully automate the process.
A few more notes about software decryption. The problem that is trying to be solved by all DRM providers is one that is not well addressed by existing cryptographic protocols. That is, what do you when Eve is Bob? In DRM the attacker is also the consumer. The best we can hope for is that only one piece of software/hardware is capable of doing the job of decryption, and that you can bake it in in such a way that no one else can use the key material. I consider this an open question. It is possible there is a great solution waiting to be discovered by researchers. It wasn't always clear that Public Key cryptography was possible -- this problem could be similar.
Your instinct is close.
key exchange is tricky but a solved problem.
True
encryption itself is trivial once you have the keys
Encryption/decryption itself is trivial in hardware. In software, its wholly non-trivial to the point that it merits investigation by the academic community.
analog holes will always exist
and
the current hard part is preventing someone from swiping your digital video stream on its way to the screen
Analog holes do exist, but its still easier to extract keys from software and decrypt wireshark dumps. Especially because this can allow you to fully automate the process.
A few more notes about software decryption. The problem that is trying to be solved by all DRM providers is one that is not well addressed by existing cryptographic protocols. That is, what do you when Eve is Bob? In DRM the attacker is also the consumer. The best we can hope for is that only one piece of software/hardware is capable of doing the job of decryption, and that you can bake it in in such a way that no one else can use the key material. I consider this an open question. It is possible there is a great solution waiting to be discovered by researchers. It wasn't always clear that Public Key cryptography was possible -- this problem could be similar.
The problem that is trying to be solved by all DRM providers is one that is not well addressed by existing cryptographic protocols. That is, what do you when Eve is Bob? In DRM the attacker is also the consumer.
That's a great way to frame the "problem", and I put problem in quotes because it really is something that looks like it has a solution.
The best we can hope for is that only one piece of software/hardware is capable of doing the job of decryption, and that you can bake it in in such a way that no one else can use the key material. I consider this an open question.
I don't know your position in the industry, bigmac, but do serious cryptographers (of which I am not) really think that there is a "solution" to the problem of Bob being Eve? The whole point of being able to send bits to Bob is that he can read/use them. If Alice doesn't want Bob to be able to read/use the bits, because he can't be trusted because he's actually Eve, then why bother sending them?
I've heard one argument being that the true purpose of DRM is to keep honest people honest, to make it just hard enough to get access to the raw data that access is discouraged. If this was the case, then a software based solution with the keys in the program is already workable, as getting access to an installed binary (where the keys would be) on an Android device is already beyond the abilities of most consumers. It really seems to me that there's this belief by the content producing portion of the industry that there is some holy grail DRM for when Bob is actually Eve. The problem isn't that Bob and Eve are one in the same in every case, it's that all it takes is one Eve to undermine all the data being sent to any Bob.
I agree that if there is a holy grail, it's not going to look like what we already have, since all the current ideas just seem like rehashes of DVD CSS, just making it harder to get at the keys, but once access to the keys is achieved, the method ends up being useless.
That's a great way to frame the "problem", and I put problem in quotes because it really is something that looks like it has a solution.
The best we can hope for is that only one piece of software/hardware is capable of doing the job of decryption, and that you can bake it in in such a way that no one else can use the key material. I consider this an open question.
I don't know your position in the industry, bigmac, but do serious cryptographers (of which I am not) really think that there is a "solution" to the problem of Bob being Eve? The whole point of being able to send bits to Bob is that he can read/use them. If Alice doesn't want Bob to be able to read/use the bits, because he can't be trusted because he's actually Eve, then why bother sending them?
I've heard one argument being that the true purpose of DRM is to keep honest people honest, to make it just hard enough to get access to the raw data that access is discouraged. If this was the case, then a software based solution with the keys in the program is already workable, as getting access to an installed binary (where the keys would be) on an Android device is already beyond the abilities of most consumers. It really seems to me that there's this belief by the content producing portion of the industry that there is some holy grail DRM for when Bob is actually Eve. The problem isn't that Bob and Eve are one in the same in every case, it's that all it takes is one Eve to undermine all the data being sent to any Bob.
I agree that if there is a holy grail, it's not going to look like what we already have, since all the current ideas just seem like rehashes of DVD CSS, just making it harder to get at the keys, but once access to the keys is achieved, the method ends up being useless.
I work for a software protection company. We have a White-box cryptography product. Setting aside the ambiguity of a term like "serious cryptographers," the best I can do is point you to this overview of the field: http://homes.esat.kuleuven.be/~bwyseur/research/wbc.php
For a more approachable introduction, see http://rdist.root.org/2007/03/23/protecting-the-protection-c... Nate Lawson (the author of that post) designed the protection scheme for Blu-Ray DVD's. One of the key features of Blu-Ray's DRM scheme is that it is renewable -- breaking one DVD's protection does not lead to breaking all protections.
A closely related field that will be very interesting to see develop is homomorphic encryption: http://en.wikipedia.org/wiki/Homomorphic_encryption. I believe homomorphic encryption is taken seriously by cryptographers, and it will help in certain situations where Eve is Bob.
There are published algorithms for white-boxing DES and AES, with corresponding papers discussing how to break those implementations. The general idea behind the publicly disclosed algorithm is to compose portions of the operation into a series of table lookups. If you're familiar with AES, think of it as the s-box transformation and the AddRoundKey transformation happening simultaneously in one lookup table. Add to that lookup tables that perform random, bijective mappings throughout the decryption operation. That gives you a feel for how one implementation works. It ends up with the same output as stock AES, just implemented in a completely different way.
The canonical attack involves fault injection. Basically, the attackers inject bad data into the state matrix during the operation. By mapping the error propagation throughout the decryption process, they are able to recover the key through some pretty heavy analysis. If you really want the details, take a look at the paper.
If you add tons of obfuscation, anti-debugging, code checksumming, and self modifying code to that library, it becomes a nightmare to figure out what is going on. DRM libraries, like malware samples, actively fight back against being examined. Now, add on top of that the fact that you are trying to launch a statistical analysis attack of the data being produced and it becomes a very hard problem. All that explanation is simply to say that using DRM in this scenario is about more than keeping honest people honest. It really is about preventing that one Eve from creating something for every Bob to consume.
For a more approachable introduction, see http://rdist.root.org/2007/03/23/protecting-the-protection-c... Nate Lawson (the author of that post) designed the protection scheme for Blu-Ray DVD's. One of the key features of Blu-Ray's DRM scheme is that it is renewable -- breaking one DVD's protection does not lead to breaking all protections.
A closely related field that will be very interesting to see develop is homomorphic encryption: http://en.wikipedia.org/wiki/Homomorphic_encryption. I believe homomorphic encryption is taken seriously by cryptographers, and it will help in certain situations where Eve is Bob.
There are published algorithms for white-boxing DES and AES, with corresponding papers discussing how to break those implementations. The general idea behind the publicly disclosed algorithm is to compose portions of the operation into a series of table lookups. If you're familiar with AES, think of it as the s-box transformation and the AddRoundKey transformation happening simultaneously in one lookup table. Add to that lookup tables that perform random, bijective mappings throughout the decryption operation. That gives you a feel for how one implementation works. It ends up with the same output as stock AES, just implemented in a completely different way.
The canonical attack involves fault injection. Basically, the attackers inject bad data into the state matrix during the operation. By mapping the error propagation throughout the decryption process, they are able to recover the key through some pretty heavy analysis. If you really want the details, take a look at the paper.
If you add tons of obfuscation, anti-debugging, code checksumming, and self modifying code to that library, it becomes a nightmare to figure out what is going on. DRM libraries, like malware samples, actively fight back against being examined. Now, add on top of that the fact that you are trying to launch a statistical analysis attack of the data being produced and it becomes a very hard problem. All that explanation is simply to say that using DRM in this scenario is about more than keeping honest people honest. It really is about preventing that one Eve from creating something for every Bob to consume.
Just wanted to say thanks for your extended answers. I haven't had time to look at the links yet, but this is exactly the sort of detail I was hoping for. I appreciate it!
I agree. Clarification would be especially appreciated for:
The hurdle has been the lack of a generic and complete platform security and content protection mechanism available for Android. The same security issues that have led to piracy concerns on the Android platform have made it difficult for us to secure a common Digital Rights Management (DRM) system on these devices.
The hurdle has been the lack of a generic and complete platform security and content protection mechanism available for Android. The same security issues that have led to piracy concerns on the Android platform have made it difficult for us to secure a common Digital Rights Management (DRM) system on these devices.
Are they only willing to use copy protection designed by the makers of the operating system they are using? I'm just speculating but this seems to be the case for ps3, xbox, wii, mac, pc, ipad.
I never thought about it like that, but now that you mention it, it does seem a likely pattern.
It's especially plausible because it frees Netflix from responsibility for content protection systems across platforms -- if one of the targets is compromised, the studios have to deal with the hardware vendor, not Netflix.
It's especially plausible because it frees Netflix from responsibility for content protection systems across platforms -- if one of the targets is compromised, the studios have to deal with the hardware vendor, not Netflix.
Android hack development has reached a point where replacing the manufacturer OS with a custom version built by hackers has become completely trivial on some leading models. not only do I see more and more nontechnical users carrying android phones, but an increasing number of them carry rooted and custom OS builds.
The office manager at my workplace found her Verizon stock OS slow,and prone to occasional crashes in trying to understand why, she stumbled about (google search)a howto article on replacing the OS in two clicks (using unrevoked, adding a zip file to your phone, and clicking some key combination), having done so, happy and empowered by the change she performed, she instructs other nontech how to own (!!!) their handsets.
The point of this story is that:
1. This is probably the intention behind why google allowed this to happen (if you check XDA developers, its thriving). in this sense phones are different then full fledged computers, hacks tend to work fine and even better then the bundle, certainly cleaner. you can download and replace your phone ROM on the fly now with rom manager (available on Google app market, and try several flavor for your own phone, (with/without htc sense, clean froyo etc..) restoring your bought apps is simple, just log into your Google account, and re download.
2. The Movie industry will shun a platform that non sanctioned (i.e not supporting DRM) developers and users can easily command, Netflix has no choice but to comply.
The office manager at my workplace found her Verizon stock OS slow,and prone to occasional crashes in trying to understand why, she stumbled about (google search)a howto article on replacing the OS in two clicks (using unrevoked, adding a zip file to your phone, and clicking some key combination), having done so, happy and empowered by the change she performed, she instructs other nontech how to own (!!!) their handsets.
The point of this story is that:
1. This is probably the intention behind why google allowed this to happen (if you check XDA developers, its thriving). in this sense phones are different then full fledged computers, hacks tend to work fine and even better then the bundle, certainly cleaner. you can download and replace your phone ROM on the fly now with rom manager (available on Google app market, and try several flavor for your own phone, (with/without htc sense, clean froyo etc..) restoring your bought apps is simple, just log into your Google account, and re download.
2. The Movie industry will shun a platform that non sanctioned (i.e not supporting DRM) developers and users can easily command, Netflix has no choice but to comply.
They are more than willing, it is what they require. That is what he is saying is the problem. Android has none 'built in', so in order to bring the app to a handset, the manufacturer of the handset has to provide it.
I don't think this is quite true. Doesn't Netflix on Mac use Microsoft's Silverlight, which is not provided by Apple? And wouldn't the streaming requirements for Hulu (which is using Flash) be the essentially the same as for Netflix? So while they are saying that the manufacturer has to provide the DRM, I'm not sure where this 'requirement' is coming from.
On PCs they chose the Silverlight platform, but what do PCs have to do with mobile devices. Silverlight isn't available on mobile devices, and choosing Flash for android deployment wouldn't help them much either. How many android devices run flash? How many of those run it well? Does anyone provide a content protection framework for Android? No, and that's the problem. What part isn't 'quite true'?
what do PCs have to do with mobile devices
I see them as pretty much indistinguishable, but maybe my perspective is skewed: my cell phone (HTC Incredible) and my laptop (Thinkpad X31) have roughly comparable processors and both run Linux. There's some differences in API, but I don't see anything inherently different about them. As time goes on, I think the blurring will continue.
How many android devices run flash
I'm not sure, but I presume that anything running Android 2.2 will. This should include all high end phones sold this year, plus everything for the future. I think most of these run it well, and would bet that all future Android phones will.
What part isn't 'quite true'?
I feel it is false to say that either Netflix or the studios require that the DRM be provided by the underlying OS. I think this is proven the existence of Netflix streaming to Silverlight in OSX. The ability of Hulu to use a flash solution also casts doubt, but this might depend on whether 'they' refers to the studios or to Netflix. But if it's a Netflix requirement to require OS level DRM, I'd wonder why they have this requirement.
I see them as pretty much indistinguishable, but maybe my perspective is skewed: my cell phone (HTC Incredible) and my laptop (Thinkpad X31) have roughly comparable processors and both run Linux. There's some differences in API, but I don't see anything inherently different about them. As time goes on, I think the blurring will continue.
How many android devices run flash
I'm not sure, but I presume that anything running Android 2.2 will. This should include all high end phones sold this year, plus everything for the future. I think most of these run it well, and would bet that all future Android phones will.
What part isn't 'quite true'?
I feel it is false to say that either Netflix or the studios require that the DRM be provided by the underlying OS. I think this is proven the existence of Netflix streaming to Silverlight in OSX. The ability of Hulu to use a flash solution also casts doubt, but this might depend on whether 'they' refers to the studios or to Netflix. But if it's a Netflix requirement to require OS level DRM, I'd wonder why they have this requirement.
How many android devices run flash? How many of those run it well?
It's the 2nd question which puts perspective on the first. No one is raving about Flash performance on Android. Netflix isn't going to release a client with poor performance. Everyone will blame Netflix for it. Of course future Android phones will run Flash fine (faster processors, more ram, whatever), but that's not a solution today. The Netflix Android clients have been in development for months (see their blog posts) and will be released in the first part of 2011 (few months). Will those Android phones that have no problem with Flash be here in a few months? If so, how many of those will there be in comparison to the install base now that netflix is trying target?
Does anyone provide a content protection framework for Android?
See that question? It's talking about 3rd party solutions. Not about DRM being provided by the underlying OS. Not sure why you are hanging on that point to call out Netflix's blog response as BS. Irdeto provides the content protection framework for Netflix to use on GoogleTV. Netflix isn't requiring the OS to have one. iOS and WM7 happen to provide their own, which is why they have clients already. Android doesn't and no one provides one.
It's the 2nd question which puts perspective on the first. No one is raving about Flash performance on Android. Netflix isn't going to release a client with poor performance. Everyone will blame Netflix for it. Of course future Android phones will run Flash fine (faster processors, more ram, whatever), but that's not a solution today. The Netflix Android clients have been in development for months (see their blog posts) and will be released in the first part of 2011 (few months). Will those Android phones that have no problem with Flash be here in a few months? If so, how many of those will there be in comparison to the install base now that netflix is trying target?
Does anyone provide a content protection framework for Android?
See that question? It's talking about 3rd party solutions. Not about DRM being provided by the underlying OS. Not sure why you are hanging on that point to call out Netflix's blog response as BS. Irdeto provides the content protection framework for Netflix to use on GoogleTV. Netflix isn't requiring the OS to have one. iOS and WM7 happen to provide their own, which is why they have clients already. Android doesn't and no one provides one.
Netflix requires OS level DRM because Netflix doesn't want to be in the DRM writing business.
But Silverlight on MacOSX isn't 'OS-level DRM'
Neither is it provided by Netflix.
So it sounds like the "OS level" part is irrelevant?
I'm not exactly sure what the underlying issue is on android devices, but at least for linux desktops, the problem is netflix uses silverlight which does have support for DRM, whereas the linux version moonlight does not. It could be a similar issue for flash on android devices, although that is just speculation on my part. All I know for sure is that I'm anxiously waiting netflix on both linux and android. I currently use a windows VM to watch netflix from my computer. On a similar note, one of the most appealing things to me about the ipad is that it does have netflix support. I would love to see it supported on android tablets.
I just want an official queue manager app from Netflix for Android.
I'm not sure you do -- queue management in the official iOS app is lousy, and streaming-only to boot (except on the iPad, where it just presents a slow webview of the Netflix site).
iPhlix has its problems, but is a much better overall package, and an indie development effort.
iPhlix has its problems, but is a much better overall package, and an indie development effort.
I'm surprised by this. Overdrive (http://www.overdrive.com/software/omc/) seems to be able to handle 'loaning' MP3s out to Android phones, so there must be some internal DRM involved that they're satisfied with.
I assume this is the same reasoning for not having Netflix streaming available on Linux.
Netflix chose MSFT's Silverlight for handling PC streaming. Lack of silverlight on Linux is the problem.
Silverlight 2 is supported on Linux by Moonlight as of late 2009. However, the implementation is lacking support for Microsoft's PlayReady DRM.
Netflix is available on Roku, GoogleTV, and the Boxee Box which all run Linux kernels. Lack of DRM is the problem. I believe the interface is authored on top of Qt and DRM is handled by special hardware in these devices.
Step 2 would be to ask why Silverlight is so important to them.
Step 3 would be to ask what does Step 2 have to do with anything?
The reasons for their choice have everything to do with why they made the choice.
Of course Roku runs Linux.
And this is why DRM is a a threat to open source. Consider what this means: Want Netflix? You need DRM. Want DRM? Say goodbye to your open-source kernel.
Thats just stupid - people can download all their content of p2p networks, but not get it legally?
Smart move, people, smart move.
Smart move, people, smart move.
From what I can gather, it seems that Netflix's product development team is frustrated to find that there is no integrated support for DRM'd media streams provided by the OS. From here, he jumps to the conclusion that the best approach is working with individual handset manufacturers to patch in support for this at the OS or kernel level. This is difficult to understand.
It's an operating system. You build things on top of it. One does not go to every PC manufacturer to add a "feature" to one.
Spectres of "fragmentation" aside, let's remember that these phones are real computers running a real Linux-based OS that run real software, written in real programming languages like C, Java, and Scala. They also have support for encrypted transports like SSL and high-quality video codecs like H.264. Heck, Adobe's even done it - secure content streaming on Android is possible, and works fine (speaking strictly of the transport and decoding layer - leave it to the bloggeurs to hash over what happens when you paint content on a screen).
These facts suggest that implementing secure DRM'd video streams and a player for them is not only possible, but much easier than working directly with two of the most backward-facing industries in technology now (film studios and mobile phone providers) to add this functionality.