Slashdot Mirror
AACS Specifications Released
An anonymous reader writes "AACS, the proposed key management scheme for HD DVD, has finally released preliminary (ver 0.9) specifications. The specs look like CSS on steroids: they use AES instead of proprietary crypto, but other than that they're basically the same. The main difference appears to be that AACS can revoke an entire player model if a hack appears against it, which I guess sucks if you own that kind of player."
Click here to get the specification without agreeing to the terms of access.
In many countries (such as will probably be with Canada soon), there will be laws stating that bypassing DPM's (digital protection measures) is allowed, and legal, if it is of legal intent. SUch as fair use, backing it up, etc.
So, if you use it fairly in a country where its legal to do so, and they "block you", is that legal too? Is their EULA more powerfull than non-American laws?
Content Scrambling System = CSS.
AACS= Advanced Access Content System.
Maybe I am an idiot but i had to actually read the article to know what the posted article was talking about.
I'm afraid I think you read it wrong.
..." is the key phrase. A given model, if this is the same as CSS, has a CSS key - not a given unit of that model. Revoking the key would revoke it for all units of that model since they all have the same key.
"... with the compromised set of keys
Nasty. DVD is offensive enough already ("You may not skip this!"), this will just make it worse. Argh.
With that in mind, it's clear that you can read what you quoted in the above sense, and indeed it's the plausible way to read it: it's not "causes a compromised device to be unable...", it's "causes a device with the compromised set of Device Keys to be unable...". Any device using this set of keys--whether it's superDeCSS or any particular machine of the sort that was compromised, or any other machine that shares the same set of keys--will no longer be able to view content--presumably only new content created after the revocation.
Related, from the spec:
So they revoke a player model as follows (omitting lots of details that aren't important to the big picture, and oversimplifying):
Each player model gets its own key ("set of Device Keys" in the specification). Data on the disc is encoded with a disc-specific data key. Given N player models, there are also N encrypted master keys, one for each (non-revoked) player model.
If a player model is compromised and the key from it used in a DeCSS-like program, they will "revoke" that key and, on all future releases, not include a copy of the disc-data key encrypted for that player.
The Aussi-Gringo FTA fucked allot of things for the Aussi's (though they thankfully avoided the worst on their government prescription drugs program). From what I saw and heard, the FTA has little to nothing in it for Aussi's (loss of domestic TV programs, lingering threats to their PBS, etc). And the DCMA-esque copyright "equivalents" required by the FTA are headed their way (if not already implemented, life +70 years anyone?). The FTA is the only reason Australia has troops on the ground in Iraq, because the misguided "head jerks" wanted that fucking thing so damned bad for whatever reason ("Oh, oh, we can mitigate problems between the US and China because of our relationships with the two countries!" - so what? When two elephants dance, all you can do is get the hell out of the way).
"1984" was ment to be a warning, not a guidebook. You hear that Kim Jong-il!? BushCo?!
see Figure 1-1 page 2 (12) of the Advanced Access Content System: Pre-recorded Video Book.
It's your job as user to figure out if your player is still licenced.
Now that's not to deny enterprising souls the right to devise methods to play it on unlicensed players, but there may be some fine print about such methods violating your EULA with the content provider...
While your opinion on the Beta/VHS case is only implied, I would like to point out that VHS was technically superior to Beta (in the areas of interest to the consumer) and this was the reason for its success. Specifically, VHS had a 2-hour recording time whileas Beta had only 1. This difference made all the difference to the consumer who could then record an entire movie without having to change tapes in the middle.
There are other things to say about this particular story, of course. There is a nice summary towards the end of this article:
here
sigs are hazardous to your health
Donate free food here
When a video recorder receives the signal, it normalises the incoming signal, resulting in the signal sent in the flyback period (which is not used for the image) being awarded most of the signal bandwidth, and the image proportion being awarded approximately none.
Bypassing such a system is left as an exercise to the reader, however it should be fairly obvious.
I am TheRaven on Soylent News
Also, contrary to what you may have heard, Blu-Ray discs will not require a cartridge. Blu-Ray discs should be more scratch-resistant than even current CDs and DVDs.
And about capacity: HD-DVD can only hold 30GB(15GB per layer), but Blu-Ray can hold 54GB(27GB per layer). In the future, Blu-Ray discs could even hold up to 200GB.
Albuquerque PC
I know absolutely nothing about CSS, but do know a few things about encryption in general. Once you have a copy of the data you are TRYING to decrypt, you can do a "known plaintext" attack -- which is fancy words for, "ah ha fuckers! Now I know what im looking for!!" Which generally makes the search space for the cracking much smaller (faster).
I dunno about anyone else but, Im sick of this bullshit. Its been 3 or 4 years since the decss fiasco and STILL linux support for dvds SUCK. I'm just not going to play ball anymore. Im not buying this hardware anymore.
Religion is a gateway psychosis. -- Dave Foley
Here's a clue: you'll need an LM1881 sync separator, a 4053 bilateral switch {or preferably something with more bandwidth}, and either a PIC microcontroller or a stack of TTL chips. The 1881 has an output which tells you when the field starts, and another output which pulses on every line. You need to count off 20 or so lines {look at the picture signal with an oscilloscope to see where the real picture starts}, during which time you must output a dummy black level with artificial hsync pulses. {You can get a clean hsync output from the 1881; use this to turn on a transistor and pull the black level down to 0V. Your dummy black needs to be as close as possible to true black, otherwise the very top and bottom of the screen will be some shade of grey. But you'll have thought of that and wired in a potentiometer to adjust it}. Switch over to the unadulterated picture signal for about 270 lines. Then go back to your dummy black for the remaining {22.5 or thereabouts} lines of picture.
..... pull it low to discharge the capacitor; let it float, allowing the cap to charge through a pot; and time how long it takes to begin reading high. The paddle controller inputs on the Atari 2600 worked exactly like that.
..... :)
If you need adjustability, use a PIC with a decent number of I/O lines. Or try using an open-drain I/O line with a capacitor to 0V
Or, you can get a proper time base corrector from a professional video equipment supplier. It'll probably cost you more than buying a load of original videos, though
Je fume. Tu fumes. Nous fûmes!
I'm a cryptographer, posting belatedly. I don't know if anyone will see this or read it but I had to comment.
_ no_fig.pdf. I will describe an over-simplified version.
Almost all of the assumptions in this thread are wrong. The system does not work cryptographically in the way people imagine. The technology makes it possible to efficiently revoke INDIVIDUAL DEVICES, not entire model lines. Every device can have a unique key, even if there are millions of them. There is no necessity or desire to make people's non-hacked players stop working. As others have pointed out, this would be INSANE. That's not how it works!
Cryptographically, this system allows the data to be encrypted to any of millions or even billions of devices, using a very short encrypted key block. What happens is that if some of those (individual!) devices get revoked, the size of the key block increases. Amazingly, the size is dependent on how many devices get revoked, not on how many devices there are. If extracting keys from a device is complicated and expensive, and not too many need to get revoked over the lifetime of the system, it will be a success.
The cryptographic technique is described in a paper from Crypto 2001 called Revocation and Tracing Schemes for Stateless Receivers by Naor et al and is available from http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl
Imagine creating a binary tree with enough leaf nodes to hold all of the devices (again, this is individual devices, not model lines). Each device is associated with a particular leaf node of the tree. Now we assign a random AES key to every node of the tree, leaf nodes and internal nodes.
At manufacture time, each device is given all of the keys corresponding to its branch of the tree; that is, the key for its leaf node, and the keys for the parent, grandparent, etc. of that node, all the way back to the root node of the tree. As long as the disk is encrypted to one of these keys, the device can play the disk. Note that even if there are a billion device nodes in the tree this is only about 30 keys that a device has to hold, which is trivial.
Now, to create a disk, initially it is encrypted to the root node of the tree. All devices have the key for that node so all devices can play it. The key block is very short. But now suppose that someone manages to extract the secret device keys in their device, they get published on the internet (as happened initially with DeCSS), and everyone is able to use them to decrypt HD-DVDs. (BTW this system is also being used for Blue-ray! Don't think that's going to be any different!) Now what do we do?
What happens is that new disks are no longer encrypted to the root key. Instead, we partition the tree into subtrees that include every leaf node except the one which got its keys published. Now we encrypt the disk data to the root nodes of those subtrees, rather than to the root node of the whole tree. This will allow every other device still to decrypt the data, but that one hacked device can no longer decrypt new disks. The size of the key block grows based on the number of hacked players.
This is an oversimplified version because the size of the key block is bigger than desired. The paper above shows a more complex system, which is actually being used, which makes the size of the key block linear in the number of hacked systems. Assuming that hacking them remains relatively difficult, this should be an effective and efficient content protection system.
Basically this is the same method being used in current satellite TV systems, and for the past few years it has been successful enough that satellite piracy in the U.S. at least is largely a thing of the past.