Slashdot Mirror
Analyst Says Blu-ray DRM Safe For 10 Years
Mike writes to let us know that a poster on the AVS forum says that the latest issue of HMM magazine (no link given) contains a quote from Richard Doherty, a media analyst with Envisioneering Group, extolling the strength of the DRM in Blu-ray discs, called BD+. Doherty reportedly said, "BD+, unlike AACS, which suffered a partial hack last year, won't likely be breached for 10 years." He added that if it were broken, "the damage would affect one film and one player." As one comment on AVS noted, I'll wait for the Doom9 guys to weigh in.
Here are some more famous last words that illustrate your point.
"From a mathematical standpoint we cannot speak of a theoretically absolute unsolvability of a cryptogram, but due to the special procedures performed by the Enigma machine, the solvability is so far removed from practical possibility that the cipher system of the machine, when the distribution of keys is correctly handled, must be regarded as virtually incapable of solution."
-German cryptographer
http://www.nsa.gov/publications/publi00004.cfm
If I have seen further it is by stealing the Intellectual Property of giants.
The SPDC VM is not Java. I don't think you've asked the right questions of your "people at IBM who wrote the JVM used to play BD+". Here's Avi Rubin describing the SPDC VM:
(In case you're wondering, the JVM is not a "MIPS-like instruction set on 32-bit registers with a Program Counter and an Instruction Filter" --- but that wouldn't stop you from implementing such a VM IN Java, just as the JVM is itself rarely implemented in hardware --- thus the "V" in "VM".)
The person I know who's involved with BD+ co-designed BD+.
Trust me I'm not swimming out of my depth. I really am writing a thesis in recursion theory and I present at conferences on this stuff to the world experts in this stuff. I get paid to prove things are or are not equivalent to the halting problem.
Now it is true that for some programs determining what inputs that program halts on is an undecidable problem (consider an interpreter it executes it's input reducing this to the halting problem) Hence the reason I was quite careful to specify that I was talking about a program known to halt '(on a given input)'. In case that wasn't clear let me spell out the theorem more precisely: there is a program S(i,x) so that if the i-th Turing machine halts on input x S(i,x) outputs the states (tuples of tape, head etc..) that Turing machine enters while executing on that input. I mean fuck if we really want to get stupid about this there are only a finite number of programs/input pairs that could be encoded in all the molecules used by the Blu Ray disk/player so there is some program (a giant case statement) that tells you how each one of them behaves.
Of course such a program is totally useless and irrelevant to the question of cryptography. Thus the reason I pointed out that the halting problem simply doesn't apply here. The question in cryptography is not whether something can be computed but whether it can be done so efficiently.
--
Now I won't claim to be an expert in cryptography the same way I am in recursion theory aka computability theory but I do know a fair bit about it (being a mathematician some stuff leaks out) and you are pretty confused.
Just consider the S-box in a normal symmetric cipher (like DES). This tells you how to modify some of the bits of your input based on the value of other bits, i.e., the value of some bits of the content you are decrypting tells you how to change the value of other bits. If you wanted to you could describe this just the same way you did the BD+ VM system. Each encrypted piece of content comes along with instructions that execute on the S-box VM (and lots of other components) that tell you how to modify other bits of the input.
Any block cipher works by letting some bits read from the input affect how you decrypt other bits. The only question is how you do it. If you could make your cryptographic algorithm more secure by exchanging nice simple things like S-boxes for complex computer like VMs they would be doing it.
So what about your claim that BD+ lets them modify the cryptography after a break making it more secure? Well like AACS does, they can revoke the keys of compromised devices but the VM plays no role here. BD+ can't do more than this as Blu Ray players bought next year need to be able to play Blu Ray disks in 3 years which means there must be some pre-established algorithm that lets the current players decode the future disks. That algorithm IS the cryptosystem, calling it a VM doesn't change anything.
At the highest level of abstraction things ALWAYS look like this. Player has some secret information. The information on the disk is somehow encrypted so that it is (supposed to be) hard to compute the content stream without the secret info. The player applies some algorithm (in this case runs the virtual code in a VM after doing some other cryptographic verification) that then produces the content stream as a function of the player secret and the data on the disk. Making this function more complex by sticking a VM inside it only makes the decryption algorithm more obscure. Once you've figured out the algorithm in the BD+ docs, i.e., the non-secret part all the manufacturers get, it's just another cryptosystem.
The reason the Palladium/TPM people use VMs and the like isn't because they make things more secure. If all you wanted to do was prevent unauthorized people from reading your HD you would just encrypt it with a nice symmetric cipher and be done. They implement a VM because it gives them more control. So long as the system'
If you liked this thought maybe you would find my blog nice too: