3 ms·

There are certain specs that anyone implementing a video streaming/content delivery service must comply with. The studios mandate that certain specs be followe

by bigmac 16y ago

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/ 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.

nkurz 16y ago
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?
- bigmac 16y ago
  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.
  - thwarted 16y ago
    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.

by bigmac 16y ago

nkurz 16y ago

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?

bigmac 16y ago
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.
- thwarted 16y ago
  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.