AACS Hack Blamed on Bad Player Implementation 272
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.'"
To be expected (Score:5, Insightful)
Re:To be expected (Score:4, Interesting)
I wonder what they're going to say when it's brutally apparent that ALL software players can be compromised. From what I can see, they have a few options, and none of them are pretty.
- play the cat and mouse game, and have the keys updated on the players while revoking the old keys.
- disallow software players all together.
- admit defeat and forget about revoking keys.
Re:To be expected (Score:5, Informative)
Of course, hardware solutions can be broken too. I can envision a couple of ways this will happen:
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: (Score:3, Informative)
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
Re: (Score:3, Interesting)
Hacking a software player is only a bit easier if you have the tools. Hacking hardware players is as simple if you are equiped with the right analyzers and equipment.
Hell if they fudged up and used sram you can halt a processor and read the contents of ram between each processing cycle pretty easily..
Re:To be expected (Score:4, Insightful)
Second, I don't think you will be able to read off keys with any kind of microscope. I don't think you'd be able to find out the key even if you had a complete wall-poster-size plot of the chip. I don't think you quite appreciate the complexity of a chip. Even low-end ASICs push millions of transistors these days. About the only method that can be used to steal keys is wafer probing, and that's pretty hard to do with modern chip densities.
Reading data from a flash EEPROM is even harder. Engineers who design chips are generally much smarter than people who try to break them, and there are plenty of tamperproof chips available. Most tamper-resistant chips now incorporate self-destruct features that erase the data when you try to probe the chip or screw around with its supply voltages or clocks. The industry has come a long way since the 16C84, which wasn't even intended to be tamperproof.
I am also not sure what your point is with regard to keys. Any secure system ultimately depends on the security of its keys.
Re: (Score:3, Informative)
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
Re: (Score:3, Interesting)
almost every pc sold in the last three years has this chip, it is called TCPA and
one of the key areas this chip should be used for was BlueRay and HD-DVD
it is just thatthere are lots of PCs nowadays which do not have those chips.
I'm mixed on this. (Score:5, Funny)
Part of me wants them to find a proper fix for these holes. My CableCo phoned me because I've already gone way over my quota this month.
Re: (Score:3, Interesting)
Re:I'm mixed on this. (Score:5, Insightful)
Imagine if the keys that got leaked came from, say, the PS3. Can you imagine the shitstorm that Sony would throw if the first million or two buyers couldn't play Blu-Ray movies anymore? Those keys would never get revoked.
Making life hard for customers doesn't mean more $ (Score:5, Interesting)
The MPAA (and Microsoft) are fighting the way their enemy fights best. If you make DRM inconvenient, and it *is* inconvenient, hackers will find a way around it. If you overcharge, or having play-one-time-only restrictions, people won't use it. If you make any system harder to use than what is out there already, people will go around it! And I'd bet my money on a bunch of teenager hackers over any boring, Microsoft wage serf.
My suggestion: make movies cheaper and drop DRM altogether. PC game companies are realising this. My Oblivion DVD says 'we didn't include any copy protection so please don't copy this'... and I didn't. They've got my goodwill. Some hackers probably did copy it, but DRM doesn't make it any more or less likely. Maybe even more?
Of course not, dear... (Score:5, Funny)
DRM is silly (Score:5, Insightful)
You give them the key.
You hope that they can't figure out how to put one into the other.
High fives.
Re:DRM is silly (Score:5, Insightful)
Not when Apple does it! (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Re:DRM is silly (Score:5, Funny)
Period.
Blame Canada (Score:5, Funny)
Even worse, the AACS specification does not, in fact, account for this large sparsely populated country.
Re: (Score:2)
Dig it [wikipedia.org]
Never! (Score:5, Insightful)
It cannot, ever, unless they disallow software players from any platform not running on Trusted Computing enabled hardware and a Trusted Computing enabled operating system.
Until then, no DRM scheme works.
None.
It's that simple.
Re:Never! (Score:5, Insightful)
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.
If it can be played, it can be copied. Playing is copying. Any manipulation of digital data is copying it. Trying to make bits not copyable is trying to make water not wet.
TPM is anti-virtualization (Score:5, Informative)
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.
Re: (Score:2)
If we own the physical hardware, DRM is never going to work. Period.
Re:TPM is anti-virtualization (Score:5, Insightful)
Similar things have been done before in so many different scenarios... Just to take a trivial example, MAC addresses were supposed to be unique for each network card, too.
Re: (Score:2)
The private key for your motherboard will be - it will never leave a single chip. Sure, if you have the hardware you can in theory obtain it, but this will require stuff like electron microscopes.
You can't make it impossible - but you can make it REALLY hard.
Re:TPM is anti-virtualization (Score:5, Insightful)
How do you account for this hole:
1) Asus' servers get "hacked".
2) The keys to all Asus motherboards get posted on the web
3) Sales of Asus motherboards skyrocket.
4) Asus issues a press release to the effect of: "It was the fault of those damn dirty hackers. We have no idea how this happened. Excuse us; we must return to sifting through this mountain of cash".
The hardware manufacturers have no incentive to play nice with the Trusted Computing scheme. This is just a repeat of DVD Region Coding. The manufacturers just started producing players that ignore the region code, because they outsold the locked players. Of course the first few on the market were "accidents", "mistakes", and "test designs".
In a Trusted Computing world, machines with a broken TC implementation will be cheaper to make and command a higher price in stores. What do you think will prevail?
Re: (Score:2)
2) The keys to all Asus motherboards get posted on the web
3) Those keys are revoked.
Re: (Score:3, Interesting)
It's a little more subtle than that.
In the first round, all the "major" manufacturers produce compliant devices (modulo bugs), which are locked down.
Then the Asian boot
Re: (Score:3, Insightful)
Thankyou (parent is right) (Score:5, Interesting)
Every time a thread about DRM comes up, TCPA is mentioned, and a whole bunch of people get modded +5 Insightful for saying that they'll circumvent it using VMware or similar. But to do that, you have to make your own TCPA keys, which won't be signed by a trusted third party. Online services that require remote attestation will require you to use a key that has been signed in that way.
The key in your TCPA module will have been signed, but you can't get at that key by design. You can't use it to sign programs in your VM. That's the idea. They know that virtualisation is a hole. They are as smart as you.
However, perhaps we can get at the key in the TCPA module by getting the module to repeatedly sign something while monitoring its power consumption. This technique, differential power analysis, is apparently very hard to defeat. You can use it to get keys out of smart cards, given enough time: perhaps you can use it to get keys out of your own processor. The price of freedom in the future?
Get informed about TCPA here. http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html [cam.ac.uk]
Re:TPM is anti-virtualization (Score:4, Interesting)
Sure, but the whole point is that you can't access the keys the "trusted" mainboard manufacturers encode into the hardware. You can program the emulator with any key you want, but it won't be one of the "trusted" keys. The keys are stored and used entirely within a single IC; the only way to extract one would be, in theory, to examine the IC directly (with an STM, for example), or somehow gain access to the master copy held by the manufacturer (and risk violating trade-secret laws).
IMHO this raises interesting legal issues, since it would tend to allow holders of one form of monopoly monopoly (copyright) to influence market shares in another industry (computer hardware). With TC the priviledged holders of media monopolies would be free to determine which hardware manufacturers succeed and which ones fail. Might not the RIAA/MPAA find themselves on the receiving end of an antitrust suit as a result of this cross-industry influence? (I don't support antitrust regulations myself, but I'm not the one they have to worry about.)
Re: (Score:2, Interesting)
Re: (Score:3, Insightful)
And the manufacturer wouldn't know your key either. Most likely the chip will generate its own keypair, store it in flash, give the manufacturer a CSR, which would then be signed and returned to the chip as a certificate. At this point the only copy of the private key is in the chip - at best the vendor knows the public key, which is no good for bypassing TPM.
Now, what you could do is get the manufacturer's signing key and make you
Re:TPM is anti-virtualization (Score:4, Insightful)
No software will be signed with any of those keys. The certificate only certifies that the chip implementing TPM is genuine.
The logic is that on bootup the TPM chip will hash the BIOS and store this has, and will provide a signed attestation upon request that this BIOS was booted.
The BIOS will then hash the OS that it boots and provide its hash upon request. The OS will do the same for a piece of running software.
A remote website will ask a piece of software for a chain of trust. The software will ask the OS for its hash, and the OS will ask the BIOS for its hash, and the BIOS will ask the TPM chip for its hash. All of these signed hashes will get sent to the remote website. The remote website will check all the hashes and decide whether to provide the software with a decryption key.
If the software is found to have a vulnerability it could be revoked at the server level. Obviously this will be a pain for anybody who owns that software, but TC isn't designed to make user's lives easy.
I agree that there are a bunch of issues with TC, but it will make extracting protected content a real pain. It might also make it harder for you to open your documents in open-source software. While you could always download an unprotected torrent of the latest movie release, you won't be able to find an unlocked torrent for the spreadsheet you created in MS Excel the other day.
My feeling is that we need legislation requiring the disclosure to computer buyers of ALL keys stored within them, and any related-keys that are needed to access features on those computers (such as any signing keys needed to flash the BIOS). And by disclosure I mean the keys themselves - not just the fact that they're there. Computer owners could use TC to secure their computers against hackers/viruses/etc, but 3rd parties couldn't use TC to secure computers against their legal owners.
Re: (Score:2, Interesting)
What is to stop a guy with a real TPM system and a virtual environment from just proxying any TPM requests/responses from the virtualized system to the real TPM module?
The TPM is like a black box right? Nobody can see inside it, all an
Re: (Score:2)
I don't see how that makes a difference - in a VM the kernel is not modified, that's kind of the whole point of a VM, you do not need the cooperation of the hosted OS.
Re: (Score:2)
Re: (Score:3, Informative)
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 entertain
Re:TPM is anti-virtualization (Score:4, Interesting)
Re:TPM is anti-virtualization (Score:4, Interesting)
You forget the third, possibly not completely possible right now, but certainly concievable in the near future, option of obtaining the key. Brute force.
It wasn't that long ago (in the timeframe of video formats) that RC5-56 was considered 'secure' enough. It might not be around the corner, but there is certainly the possibility that CPU power could continue to ramp up quickly enough that the keys themselves can be brute forced through a botnet version of distributed.net. And once that cat is out of the bag, it'll be out forever.
Re: (Score:3, Insightful)
A. It assumes that the key will be the last possible one in the key space.
B. It assumes that the only method used will be 'pure' brute force.
A. is almost certainly not true. And while it might be optimistic, it's quite possible that it'll be discovered that due to some brain dead maneuver the keys themselves have been generated weakly in a fashion where all 128 bits don't really come into play.
B. might be true for now, but I refuse to believe that there aren't alr
Re: (Score:2)
Before anybody else ask, as you may imagine, they have gone far enough with TPM so that making a trusted application is a bit more difficult than switching a property in the config file.
There is no *obvious* flaw in TPM ( there may be flaws, but nothing that you could think in 5 sec: like running a VM, changing the registry, blinking your eyes real fast ).
Actually in theory, TPM is really cool and could mean the end of viruses,
Re: (Score:3, Interesting)
Then you degrade the problem to a Man in the Middle, where your microcode simulates a processor and performs some operations before/after sending to same
Re: (Score:2)
But will these virtualization kits have the TCPM-enabled BIOS? What about open source virtualization kits? IIRC, Mac OS X can run in a virtualized environment only once the checks for the hardware DRM are removed by a hack. It seems like there would be copyright or patent issues that would prevent a FOSS virtualization kit from run
Re: (Score:2)
And this only works because MacOS X needs to be able to run offline.
Once your HD-DVD player is required to be hooked up to the internet to work, that hack will stop working. The key to your DVD won't be stored on the DVD - instead you'll download it each time you play it. However, the server hosting the key won't provide it unless you pass a TCPM check - if the hashes of the bios/OS/player aren't
Re: (Score:2)
Re: (Score:2)
No AACS, Blu-ray, HD-DVD for me. (Score:4, Interesting)
I'm glad I made that decision. All this new crap involving DRM and frivolous from the entertainment industry just goes to show you how full of horseshit they are. I'm very pleased that my money does not go to them. They don't deserve it. Not only that, but now that I play sports rather than just watching them on TV, I've become much more fit and far healthier. Getting away from the mainstream media was one of the best things I've ever done.
Re:No AACS, Blu-ray, HD-DVD for me. (Score:5, Funny)
Re:No AACS, Blu-ray, HD-DVD for me. (Score:5, Funny)
Re: (Score:2)
Ed Felten writes about an economic model... (Score:5, Informative)
...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.
Ahh... the fun begins! (Score:5, Interesting)
Players which will only play certain discs and not others, instant obsolescence for entire classes of $1000 players.
This makes the format wars look like a sales promotion!
Re: (Score:3, Informative)
Re: (Score:2)
Well, sure it is - but it would be a lot harder to pull off.
Yeahbut... (Score:2)
Re:Ahh... the fun begins! (Score:5, Insightful)
In short, AACS is doomed if it does, doomed if it doesn't.
Re: (Score:3, Interesting)
The industry NEEDS the word-of-mouth. And as it stands, that word-of-mouth is negative. It's "yea, the picture is great, but then there's all this other stuff you'll have to deal with." That's not going to fly.
-S
Individual players are revoked, not classes (Score:2)
Re: (Score:2)
A billion keys isn't all that unrealistic a number. Sure, I guess it could be done, but it sure is an interesting approach.
Plus, in this particular case they wouldn't know the key for the piece of hacked hardware - they didn't disclose the software key - only the media keys.
Re: (Score:2)
Obviously AACS LA will have to know which players to revoke, but I suspect hackers will start leaking player keys soon, since they're more useful than title keys.
Re: (Score:2)
Re: (Score:2)
I meant to say something like this:
"You don't brick entire brands or even just single models, you brick single players. It's easily possible to do that efficiently with the new method."
Re: (Score:2)
Even if each player did have a unique decryption key though, they would have no way of knowing which key to revoke. This is the reason the per
Re: (Score:2)
My interpretation of the spec is that every individual player has unique keys. Software players may be a little more relaxed, though.
It is at least a class of players (in this case we're only dealing with software players as a sibling post has pointed out) and I wouldn't be surprised if they keys were only unique on the manufacturer level (i.e. Sony has one key for all the players it makes).
The software players may have one set of keys for
Re: (Score:2)
Updated? Battle of the Rootkits! (Score:4, Interesting)
If the players are non-patchable:
1) We will live in a universe in which, every year or so, an unknown number of players will play discs produced up to, but not after, a certain date.
Consider the sales/support implications of customers selecting products for Christmas 2008: "Well, sir, this Foobar-1000 plays discs up produced in 2006-2007, a Foobar-1130 plays discs produced from 2006-2008, and a Fonybaz-1900 plays discs produced from 2006 to August 2008."
If the players are patchable, it's even worse for the industry:
1) Your Foobar 1000 will play discs produced in 2006 and 2007. It ceases to work for discs produced between February 2007 until you buy a disc produced a few months later that happens to contains some code that query the player whether it's a Foobar 1000... and if so, to automatically/silently patch the firmware. Then all your discs work again.
That's a good thing for the user, and a bad thing for the industry, because as soon as you've got a firmware patch on a DVD, the obvious thing for an enterprising hacker to do is to put his own firmware patch on his own DVD, and your Foobar 1000, all of a sudden, ceases to implement the DRMish crap which the MPAA crammed onto it...
In short, if players can be patched in the field (and this applies to both hardware/firmware-based players in embedded systems and to PC-based disc-playing software), it's a long-term battle of the rootkits, and that's a battle that MPAA is likely to lose.
Re: (Score:2)
Except that this is a "class break": it affects all players of the same type. If they revoke the cracker's player's individual key, the next 100 crackers continue blithely along unaffected. They have to revoke the keys for all players of the vulnerable type to stop the break. Which will always affect more legitimate customers than crackers.
Re: (Score:3, Informative)
Suffice it to say, the design of all of them is flawed from the get-go, so whatever.
I thought the player key hadn't been revealed? (Score:5, Insightful)
Not that it matters much either way because this attack vector will always exist for any kind of system they come up with. Since it will always exist someone will rip it and post the movie on bittorrent.
They are actually probably pretty happy that this is the only possible hack anyways since it isn't anywhere near as useful as DeCSS.
Re: (Score:2)
And that's the lynchpin to the whole DRM debacle. All it takes is one individual somewhere on the planet to manage to crack or circumvent the encryption on any given movie to make it available to everybody. It may take some time but it's likely to happen eventually.
Re:I thought the player key hadn't been revealed? (Score:5, Funny)
And, unlike the disc you legally purchased, the cracked version is pretty much guaranteed to actually play on your hardware.
bwa.ha.ha. (Score:3, Interesting)
Please check our website so you can download a patch and intall it on your DVD player.
BWahahaha..
That will go over like a lead balloon.
as will a machine that no longer playing new movies every few months so you have to buy a new player.
Which is good. DRM is just causing more consumer frustration and less value.
they can't patch these holes away (Score:2)
Revocation is pointless (Score:2, Insightful)
Why bother revoking the key? I must be missing something. Sure, don't use the same key on future discs, but pirated copies will have no encryption
Re: (Score:2)
Re: (Score:3, Interesting)
http://en.wikipedia.org/wiki/ROM-Mark [wikipedia.org]
I'm not sure if HD-DVD has a similar feature, or if this is Blu-ray only.
Hmmm i swear thats not the way i read it.... (Score:2)
wasnt this attack based on being able to extract the title-key from the disc, then run it through stock AACS decryption libraries? they could revoke whatever keys they wanted, but wouldnt the existing un-retractably released software still have to read the key (making it visible, unencrypted, in ram....) before it could deny playing it?
The way i understand it t
Something they seem to be ignoring (Score:4, Interesting)
Selective keying using the whole .exe from memory. (Score:5, Informative)
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.
I need to buy, rip, and store the content (Score:5, Interesting)
Hear that, MPAA!?!?! I said BUYING. You claim piracy costs sales, but you MUST then subtract the lost sales due to your overbearing copy protection. I have about 2000 CDs and about 600 DVDs in my collection. I have no HD-DVD or Blu-Ray discs. And I don't plan on it either unless things change.
It's a new world. And in this new world, I have an expectation of device portability. That means when I buy a 5" media-containing silver platter, I expect to be able to store it on a server in my house to stream it to my living room or my computer or my bedroom. I expect to be able to re-compress it for my laptop or my ipod (or -like device) for watching when traveling. I have no desire to be tied to a specific (and expensive) playback device in a specific location. You're terrified of future storage capacity that will reach into the terrabytes on small devices, but to me, that's the thing that's keeping me interested at the moment in the stuff you have to sell... the knowledge that I can have that portability in movies and TV the same way I have it for the music that I've collected over the years. The RIAA freaked out when MP3's came along, but to be honest, my interest in music had waned significantly. But now, with so much available at my fingertips, I'm VERY interested in hearing new things and I'm buying probably more than ever before (though none through the DRM-crippled iTunes store).
I will gladly buy the media, but I expect that at that point, our relationship is OVER. Thanks, goodbye. Now if I want to extract images from the movie, print them out, and wall-paper my room with them, that's MY business, not yours.
-S
Re: (Score:3, Funny)
I think MPAA just pissed its pants.
Re: (Score:2, Funny)
Wrong audience, pal (Score:3, Insightful)
Bring it on! (Score:4, Insightful)
So magine the shit-storm when customers start flooding the Best Buy customer support aisle thinking that their machine is broken, when if fact it "works" just fine and the movie industry has shut down your player because some hacker is using its AACS key.
I can't wait.
Re: (Score:2)
And in other news: (Score:5, Funny)
The Titanic did not sink, it was just that Captain Smith did not adhere to the specifications as to how the Titanic should be operated (it says clearly on page 216, "Do not allow icebergs to rip open more than four of the water-tight compartments.")
And talk of "blunders" in the Battle of Balaclava are hogwash.
Re:And in other news: (Score:5, Informative)
I agree with your main point though. Their statement was pretty silly.
early adopters, instantly obsolete! (Score:2)
"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.."
which roughly translated into English means
"anybody hacks the Belchfire player, we just lock out new titles. Belchfire fixes it for you, or you pound tar, customers. Bwa-ha-ha-ha-ha!"
just what we all needed to hear to make us want to run out
Re: (Score:2)
Their only logical option (Score:4, Insightful)
Vicious circle of blame (Score:3, Informative)
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].
Well, Is that so? Not! (Score:4, Insightful)
All you need is one very pissed-off average geek that can't watch their bought-n-paid-for movie and the whole non-DRM'ed movie is likely going to be out there for everyone else, that can't watch their own copy, to download it. In fact, the more players that they "revoke" the keys for, then the more pissed-off geeks there will be, and the more movies that will likely be available for download. Its a loosing proposition any way you look at it. With DRM the "fix" becomes "the problem". The only people that win are the ones writing the DRM and spoon feeding the Board room executives that don't know that DRM can't work.
When will they ever learn that you can't solve a SOCIAL PROBLEM using technology of any kind. In fact they should wise up and realize that its the professionals that build specialized hardware that copy the "protected" disk bit-by-bit, then burn a thousand copies, and are making big bucks off of all the boot-leg copies. Those are the ones they should go after, not the average people that paid for the movie and just want to watch what they paid for, when and where they want to. So, RIAA/MPAA, take it from a security geek, know thy enemy! You can't fix a problem if you don't even try to understand what the problem is!
Malware, and why they made this statement (Score:4, Insightful)
1. The most devastating attack that can be done against software players would be to use malware to extract keys. There are many, many zombies out there. The malware could search for installed HD-DVD/Blu-Ray player software on the victims' machines that it knows how to break, extract the unique key from such software, and send to the malware author. There would then be enough keys known that only revocation of the entire product line's keys could get around the problem. I wonder whether they've considered this scenario. (However, one mitigating factor is that malware is done for profit, and this wouldn't be profitable. For-profit pirates just copy disks outright without bothering to decrypt.)
2. The reason the AACS made that wording about the players not following the "Compliance and Robustness Rules" is probably so that they can invoke the parts of the contract allowing them to fine the licensee millions of dollars.
Re: (Score:3, Insightful)
It warms my heart to know that there are people out there watching out for my fair use rights. If it weren't for them, the peop
Re: (Score:2)
On the other hand, I purchase my movies (currently on DVD) and am very happy that DeCSS exists. It al
Re: (Score:2)
Re: (Score:3, Insightful)
I'm positive someone will find a way around THAT, too. Even if it means applying a soldering iron to a motherboard. Some people are very creative. And the fun part is, you only ever have to hack it ONCE, and the internet does the rest...