Netflix on Android
blog.netflix.com
blog.netflix.com
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
iPhlix has its problems, but is a much better overall package, and an indie development effort.
Smart move, people, smart move.