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.'"

Ed Felten writes about an economic model...

[Saint Aardvark]

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

Re:Ahh... the fun begins!

[Sircus]

I'm no fan of the content mafia, but all they're talking about at the moment is disabling certain software players which the publishers could easily offer free updates for. The current crack isn't applicable to hardware players.

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:Another blow struck for free entertainment

[HomelessInLaJolla]

You would make sense if a money map of the industry didn't show that the vast majority of the profit goes to CxOs, VPs, board directors, and career stock investors who have little or no real interest in the actual entertainment content.

When you can separate honest entertainment interest from pure and erated business interest then you may pull your head from your backside.

Re:Hmmm i swear thats not the way i read it....

[Anonymous Coward]

wasnt this attack based on being able to extract the title-key from the disc, then run it through stock AACS decryption libraries?

It was, but the title keys are encrypted with the disk key. There are lots of copies of the disk key in a single file on the disk, all encrypted with one of the many player keys. If a player key is revoked, there will simply be no copy of the disk key that this player will be able to decrypt on any future disks.

Vicious circle of blame

[ThePhilips]

AACS hack is blamed on bad player implementation

As programmer, I can tell that it work both ways. Any deficiency (or bug) can be blamed on poor implementation. At the same time, big companies which actually looked and benchmarked development process (e.g. IBM) claim that 75% bugs are caused by erroneous specifications.

IOW, players were implemented as good as AACS has told what/how to implement.

Somehow, I doubt that documentation from AACS would be much better than that of Microsoft [slashdot.org].

Re:DRM is silly

[et764]

Still, the machines are made up of electrical pulses moving across the chip. These electrical pulses can be observed and manipulated. As long as you have physical access to the playback device, which won't go away as long as you can use your media at home, there exists some way to get the hardware or software to reveal the key. It may take a whole lot of creativity, trial and error, but it can be done.

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 [microcontroller.com] 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 [brouhaha.com] 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. [about.com] 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.

Re:TPM is anti-virtualization

[Cheesey]

Well, there's the PPC chip in the XBox 360, for one. That's a full TCPA system.

Please bear in mind that I'm only arguing this point because I think it's important that people are well informed about what we're up against here. It's not going to be easy to get around TCPA, really it isn't. Virtualisation and man-in-the-middle attacks are exactly what TCPA is intended to prevent, and it's been designed by people who understood what sort of work would need to be done to enforce DRM as required by the entertainment industry.

However, citations. Anderson [cam.ac.uk] says that current (2003) TCPA chips are on the motherboard, not the CPU, but:

However, in a few years, the Fritz chip may disappear inside the main processor - let's call it the `Hexium' - and things will get a lot harder. Really serious, well funded opponents will still be able to crack it. But it's likely to go on getting more difficult and expensive.

He also notes that some portions of TCPA are already in your CPU:

The operating system security kernel (the `Nexus') bridges the gap between the Fritz chip and the application security components (the `NCAs')... Finally, the Nexus works together with new `curtained memory' features in the CPU to stop any TC app from reading or writing another TC app's data. These new features are called `Lagrande Technology' (LT) for the Intel CPUs and `TrustZone' for the ARM.

With the chip on your motherboard, yes, you can do a MITM attack on the bus lines. That and cost saving is exactly why it'll be part of your CPU, if it isn't already.

Re:To be expected

[dr_labrat]

yup, and there it is folks.

For the uninitiated, (i.e. non-security chaps), fundimentally when it boils down to it, its irrelevant how good the encryption mechanism if someone is sitting over your shoulder reading the information.

I really wish the DRM happy crowd would understand that if it gets to be decrypted by a bit of kit that can be in "hostile" hands it is not going to be "secure" for more than 2 months (see DeCSS, Fairplay, Microsofts thingy, BlueRay, um.... Wait... all DRM thus far has been cracked in less than 2 months.).

Frankly its absurd. You employ a team of 50 programmers to make the next greatest hack proof DRM schema, however you are (if you make anything worth viewing/listening to/playing) up against at least 1,000 times that in terms of people that are interested in breaking it.

The worst thing is: The crackers only need to find one way to break it.

Hey ho. The reality of the situation is that DRM is costing the media conglomerates more to implement than the potential losses.

Its like putting a $200 lock on a $20 bike.

If I like I buy. If I can I take. If had taken, it doesn't mean I would have bought it.

If I like something I have taken I will buy it.

Re:Updated? Battle of the Rootkits!

[pyite]

Your parent's point is that if you obtain the player key for HDVision-1000 serial number ABCDE, just revoking the key for serial number ABCDE is not enough. Since you can obtain the key from one HDVision-1000, you can easily do it to any other amount of the same model, thus they keys for ALL of that model must be reversed, since the design* has been compromised.

Suffice it to say, the design of all of them is flawed from the get-go, so whatever.

Re:To be expected

[smallfries]

ASICs are not expensive if you're designing a high-priced piece of consumer electroncis where you can absorb the cost into your fat generous margins. If you're aiming at the disc player market then you're competing against cheap imports. DVD players are now so cheap here that you can't give them away (about £30 last time I looked).

But we're not talking about a common ASIC for each player - you've twisted the GPs point. We're talking about a unique ASIC for each player, and making runs of 1 ASIC would be unimaginably expensive. Hence the FPGA route would need to be taken to avoid a single key across the players.

Reading keys off with a microscope has been done. That is how the 2048bit Xbox private key was compromised. Of course the gradstudent that did it couldn't tell anyone what it was, and had a Microsoft goon at each one of his seminars, but it still prooves that it can be done.

Nobody has ever made a tamper-proof device. There are many approximations on the market - things that will resist X amount of tampering before they fail, but any tamperproof box will fall to a determined adversary. When tamperproof casing are designed, the measure used is how much effort / cost can we force the adversary to use before they gain access.

The GPs point was that, by necessity, DRM requires unencrypted information to be hidden in plain sight. Furthermore, this "secret" is common. So there is a single point of attack in the system, which when breached compromises the entire system. This is his point with keys that yuo missed. DRM cannot work unless the the secret keys are available in plaintext. Hence the system is always screwed, by design.