3 ms·

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 Netfli

by 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.
- bigmac 16y ago
  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 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-code/ 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 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.
  - 16y ago

by bigmac 16y ago

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.

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