I've read through this post a few times and am having some difficulty understanding both the original problem and the solution that Greg is suggesting.
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.
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.
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.
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.
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'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'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.
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.
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.
[+] [-] cscotta|15 years ago|reply
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.
[+] [-] bigmac|15 years ago|reply
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.
[+] [-] sukuriant|15 years ago|reply
[+] [-] nkurz|15 years ago|reply
[+] [-] bigmac|15 years ago|reply
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.
[+] [-] mattparcher|15 years ago|reply
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.
[+] [-] nutjob123|15 years ago|reply
[+] [-] chewbranca|15 years ago|reply
[+] [-] RK|15 years ago|reply
[+] [-] irons|15 years ago|reply
iPhlix has its problems, but is a much better overall package, and an indie development effort.
[+] [-] FiddlerClamp|15 years ago|reply
[+] [-] waterlesscloud|15 years ago|reply
[+] [-] YooLi|15 years ago|reply
[+] [-] RK|15 years ago|reply
[+] [-] teilo|15 years ago|reply
[+] [-] tomjen3|15 years ago|reply
Smart move, people, smart move.