Analyst Says Blu-ray DRM Safe For 10 Years 493
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.
Re:A question or two (Score:1, Informative)
You'll never write a legal free player for protected movies though.
Re:famous last words (Score:5, Informative)
"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 [nsa.gov]
Re:famous last words (Score:4, Informative)
PGP and media encryption schemes are completely different animals. As long as they keep making software players for these discs their encryption will be broken.
Re:famous last words (Score:4, Informative)
That's pretty much true, you know. IIRC, in the later days of WWII Enigma mesages were decyphered rather quicky because operators weren't working key schedules as they should. Some tidbits here [wikipedia.org]. Still, calling a cyper system "unsolvable" is just asking to be made a fool
Re:It's not really just an encryption scheme, thou (Score:4, Informative)
There are a lot of DVDs that the now ancient DVD-Shrink can't rip without help - they typically have bad sectors that the playback/menu structure knows how to avoid, but anything that tries to read the sectors sequentially will have problems with. The state-of-the-fart for this tactic is macrovision's "Ripguard" but, as you can see from this posting, it is still easily circumvented, and is hardly designed to manipulate the ripping program to execute new code:
http://forum.doom9.org/archive/index.php/t-1%20%3
Re:Sigh, I hate to burst your bubble... (Score:5, Informative)
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 [securityevaluators.com]:
(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+ [root.org] co-designed BD+.
Re:In some ways yes... (Score:3, Informative)
After all the AACS system is basically just read off the encrypted media key (or whatever it is called) off of the disk and use a private key built into the player to decrypt it. If you assume that this can't get compromised then AACS is perfectly secure. If you assume it can get compromised then the emulated VM uses that very compromise to lie about the correct response.
Actually it's a little worse than that even. We get to WATCH how the VM code tries to verify the response from the VM as it executes in our emulator. Now sure the authors can employ techniques designed to confuse us but we have strictly MORE information we can use to crack the VM based security than we did to crack the basic non-VM AACS style security.
Re:famous last words (Score:2, Informative)
Re:It's not really just an encryption scheme, thou (Score:5, Informative)
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'