AACS Hack Blamed on Bad Player Implementation

seriouslywtf writes "The AACS LA, those responsible for the AACS protection used by HD DVD and Blu-ray, has issued a statement claiming that AACS has not been compromised. Instead, they blame the implementation of AACS on specific players and claim that the makers of those players should follow the Compliance and Robustness Rules. 'It's not us, it's them!' This, however, does not appear to be the entire truth. From the Ars Technica article: 'This is an curious accusation because, according to the AACS documentation reviewed by Ars Technica, the AACS specification does not, in fact, account for this attack vector. ... We believe the AACS LA may be able to stop this particular hack. While little is truly known about how effective the key revocation system in AACS is, in theory it should be possible for the AACS LA to identify the players responsible for the breach and prevent later pressings of discs from playing back on those players until they are updated. As such, if the hole can be patched in the players, the leak of volume keys could be limited to essentially what is already on the market. That is, until another hole is found.'"

Comments

Ed Felten writes about an economic model...

[Saint Aardvark]

...for this fight at freedom-to-tinker.com. The whole series on AACS is worth reading, as is every single thing he posts.

TPM is anti-virtualization

[tepples]

And at that point, virtualization kits will become commonplace that run Windows in a sandbox so that Windows thinks it's in a Palladium environment, but where it's really not.

The express purpose of "Trusted" Computing is to distinguish an OS running on bare hardware from a virtualized OS. The virtualized Trusted Platform Module is issued not from a recognized mainboard manufacturer's keyspace but from VMware's.

Selective keying using the whole .exe from memory.

[russ1337]

They talk about this on Security Now, Episode #76 (http://www.grc.com/securitynow.htm)

It seems muslix64 just had a snapshot of the entire .exe running in memory, then used selective keying - serially trying bytes 1-4, then 2-5, 3-6 etc as the keys until the mpeg frame decrypted. (which, of course this is much faster than a pure brute force attack, and took only seconds).

So as long as a software player has the key in the clear and is loaded in memory 'somewhere', this type of attack will continue to work.

AACS is still 'unbroken' but like many failed encryption schemes, it was circumvented due to poor implementation.

Re:To be expected

[MoxFulder]

I wonder what they're going to say when it's brutally apparent that ALL software players can be compromised.

In my mind, we're already there :-) The logical next step is to allow only hardware and partial-hardware players. For a PC, this would mean having some kind of "trusted" chip on your motherboard which can encrypt and decrypt data using keys that are hard-wired in.

Of course, hardware solutions can be broken too. I can envision a couple of ways this will happen:

• If the keys are truly embedded in the "trusted" ASIC: Making custom chips is expensive. There are substantial setup costs for each new mask, so there will be enormous economic pressure to only have one or a few versions of the chip. This means once one version gets cracked, millions of computers will be freed. What will it take to read the keys off an ASIC? A scanning electron microscope, that's what. As a bored physics grad student currently sitting 10 feet away from an SEM, I can tell you it'll happen :-)
  
• If the keys are somehow individualized to each computer, they'll be stored on a flash-based FPGA, or in some kind of microcontroller's flash memory. Manufacturers of such flash-based devices go to great lengths to make it so that the code stored in flash can't be read off of the device, but this is nothing more than the same ol, same ol security through obscurity... figure out the magic voltage that you need to apply to pin 12, and oops there goes the security. Smart card hackers have already figured out ways around the protection in the common PIC16C84 microcontroller.
  

Bottom line: DRM is futile because it requires the distribution of a SECRET PIECE OF DATA (the decryption keys) in UNENCRYPTED form (the keys themselves must of necessity be unencrypted). All the crap interposed between the user and the keys is merely security through obscurity. QED.

Re:And in other news:

[cant_get_a_good_nick]

I know you meant this as a sarcastic comment, but..

The Hindenburg did not catch fire, it was merely the hydrogen in the Hindenburg that caught fire.

The thing that made the hindenburg so dangerous actually was the skin; hydrogen was just an aid. They took a small piece of the skin (very small, since it's historical item now) tried to light it on fire, and it went up like it was doused in gas. Since that was the skin, i guess you could say the Hindenburg did catch on fire.

I agree with your main point though. Their statement was pretty silly.