Understanding Key Conversion Data?

[FoxDisc]

I'm not sure if I fully understand how Key Conversion Data is supposed to improve security. I've read the AACS specs and it appears that the KCD is supposed to prevent device keys from one class of devices (hardware players?) form being directly used with another class (software players).

I also understand that when a device is required to use KCD, its device keys produce a media key precursor, not a media key. It uses AES-G with the precursor and KCD to get the media key. Then it uses the media key normally with the volume id to get the VUK.

What I don't understand is why this extra step with the KCD is used. The KCD seems to be stored in the lead-in right next to the second half of the VID. That's the easy part to read - easier than the BCA anyway. If an attacker can read both halves of the VID, then why would the AACSLA think that making him read the adjacent KCD would make things more secure?

I notice that the specs say: "The Key Conversion Data shall be stored in a manner that cannot be read by open platform drive."

Are "open plateform drives" (like the xbox drive) somehow prevented from reading the KCD even when they read the adjacent VID half?

[Johhn]

It's late, and I am tired, so the following might look like rubbish in the light of day. But......

KCD is optional on hardware players and not used at all on software players.

I wonder if it is to cater for the contingency that someone wants content to only be used on specified hardware players (as per games disks and specific machines). The disks could be keyed so as only to play on the specific type of player, and the KCD would be an added layer of security to try to prevent software emulators being developed - especially if the KCD is only readable by specific drives.

[KenD00]

You seem to mix the things up, the BCA section is the easy one, the lead-in is the the no-go. Even with the latest XBox-drive hack whichs allows to read the corresponding raw sectors returns nothing more than a bunch of zeros. The hack however lets you read out the VID because it enables the corresponding aacs command to read the vid unauthentified. But there is no aacs command for reading the KCD. So currently, afaik, there is no way to get your hands on the KCD (with the XBox-drive), but maybe some information has not reached me yet ;).

And KCD is not optional, it is required for drives (hardware players only?) that do not perform drive-host authentication and forbidden for ones which do (software players only?).

:rolleyes:

[awhitehead]

KCD commands are implemented using vendor specific CDBs on drives that support them.

[FoxDisc]

the BCA section is the easy one, the lead-in is the the no-go.
That explains it. I thought the xbox hack was reading all sectors. So at this point even having the device keys from a hardware player might be of no value provided that they are using KCD. Do we even know if KCD is in use by hardware players?

[awhitehead]

That explains it. I thought the xbox hack was reading all sectors. So at this point even having the device keys from a hardware player might be of no value provided that they are using KCD. Do we even know if KCD is in use by hardware players?

I've read reports of people taking the NEC HD-DVD drive out of first generation Toshiba HD-DVD players, and attempting to plug them into PCs. Interface is the same - IDE, and the BIOS detects the drive fine. Specific report I've read indicated that while the drive would read DVD and audio CD fine, it would not read HD-DVDs, and using aacskeys on it would fail.

Since the drive is from the hardware player, this leads me to belief that yes, at least first generation Toshiba players use KCDs.

Further, I was told that the same model of HD-DVD drive, HR-1100A, was for a while available retail, and they read/play HD-DVDs OK (http://www.digit-life.com/articles2/optical/nec-hr1100.html). So we are dealing with the feature that is firmware controlled.

Thus if you extract the hardware keys from a stand-alone player, you need to use a stand-alone's drive to use the keys.

As an aside: If anyone has a NEC HR-1100A HD-DVD drive, please PM me.

[awhitehead]

Back to KCD...

It occured to me that we actually have a very interesting example of KCD drive vs open platform drive: "Relentless Enemies" HD-DVD.

This is an HD-DVD with a mastering error, where the second part of the VID is corrupt. When I posted a VUK for it, I've read the BCA, and guessed what the second half of the VID should look like, and attempted generating the VUK, and then verified the guess. Took about a dozen tries, since I had some intelligent guesses to cut down on the search space.

But that's irrelevant. What's relevant is that this is the disc that doesn't play in the Xbox HD-DVD add-on (at least until mid-may update), and doesn't play in second generation Toshiba stand-alones - HD-A2, etc. BUT it plays in HD-A1 and HD-XA1. We also know (see my previous post) that first gen Toshibas use KCDs, since the NEC HD-DVD drive in them doesn't work in a PC with WinDVD/PowerDVD for playing HD-DVDs.

Thus it's logical that KCD sectors on "Relentless Enemies" are not damaged, and thus the player that uses KCD to obtain VUK can do so.

We know that Xbox HD-DVD addon (Toshiba SD-S802A) is designed as "open platform drive" and doesn't read KCDs.

This leaves a question: Why is it that second generation Toshiba players couldn't play back this disc?

My speculation is that second generation Toshiba stand-alones might actually not be using KCDs, and thus their device keys/private certs would work with PC drives/PC software for decrypting and playback.

Does this make sense?

P.S. This also means that attacking first gen Toshibas is not all that useful, least you want to write the software for the KCD authentication for PCs, and then use it with the specific NEC drive with the Toshiba firmware. That makes it very much more a niche product then Xbox HD-DVD drive.

[FoxDisc]

Thus it's logical that KCD sectors on "Relentless Enemies" are not damaged, and thus the player that uses KCD to obtain VUK can do so.
...
This leaves a question: Why is it that second generation Toshiba players couldn't play back this disc?

My speculation is that second generation Toshiba stand-alones might actually not be using KCDs, and thus their device keys/private certs would work with PC drives/PC software for decrypting and playback.

Does this make sense?

My understanding of KCDs is that a device using KCDs will calculate a Media Key Precursor from its DK/PK/C-Record while a device that does not use KCD directly calculates the Media Key with its different DK/PK/C-Record.

The KCD-using device uses KCD and AES-G with the Media Key Precursor to calculate the Media Key, and that final Media Key is the same number that the non-KCD-using device got directly. Both devices then have to read the VID and use it in the same way to get to the same final VUK.

If that's correct, then we have to question why the disc works with any player - since the VID is always needed.

[awhitehead]

My understanding of KCDs is that a device using KCDs will calculate a Media Key Precursor from its DK/PK/C-Record while a device that does not use KCD directly calculates the Media Key with its different DK/PK/C-Record.


Ah, hah. What AACS spec documents the KCD usage?


The KCD-using device uses KCD and AES-G with the Media Key Precursor to calculate the Media Key, and that final Media Key is the same number that the non-KCD-using device got directly. Both devices then have to read the VID and use it in the same way to get to the same final VUK.

If that's correct, then we have to question why the disc works with any player - since the VID is always needed.

Is the Volume ID stored in a unique location on a disc, that both KCD using and open platform devices access? Or is it stored in differnet locations and KCD devices can't read the open platform VID and vice versa?

It is also possible that the mastering error on "Relentless Enemies" is very platform (in this particular case laser mechanism) specific. There are discs that are not readable by the NEC HR-1100A but read fine in Toshiba SD-S802A (ex: Studio Pathe releases, such as "Stalingrad"). There are discs that have unreadable/corrupt sectors under Toshiba SD-S802A but play fine in a stand-alone using NEC HR-1100A drive (ex: National Geographic's "Relentless Enemies"). If that's the case, then all of my speculation above is right out of the window. After all we are still very early in HD-DVD game, so filesystem and mastering specifications are still very much unfinalized.

(As an aside: here is another example (http://www.avsforum.com/avs-vb/showthread.php?p=10662595&&#post10662595) of the specification changing)

[FoxDisc]

Ah, hah. What AACS spec documents the KCD usage?


The Common Spec has basics and the HD and Bd specs have specifics. Here's the common specs info:

Note that for a device that is required to use Key Conversion Data (KCD), processing of the Media Key Block
will result in a Media Key Precursor Kmp instead of a Media Key. The rules applicable to devices that use KCD
are in the AACS Compliance Rules. The use of Kmp in devices prevents the direct use of compromised Device
Keys from those devices in a different type of device that does not use Kmp. To obtain the actual Media Key,
the Media Key Precursor must be processed with KCD using the following process:
Km = AES-G(Kmp, KCD)
The device obtains the Key Conversion Data by mechanisms that are independent of the Media Key Block.
These mechanisms are defined in the format specific books of this specification. A device that is useing KCD,
generally must apply the KCD before verifying the correctness of its processing of the Media Key Block.
However, it is possible that it may be processing an old Media Key Block to which the KCD data has not been
incorporated in its part of the tree. Therefore, such a device shall use the Verify Media Key Record to determine
if it needs to apply the KCD data or not. In other words, if the purported Media Key Precursor actually verifies
as the Media Key, then it shall not apply the KCD data, even if it is a type of device that normally would use
KCD data.
Devices that do not use the KCD are not required to verify the Media Key, although they may.

Is the Volume ID stored in a unique location on a disc, that both KCD using and open platform devices access? Or is it stored in differnet locations and KCD devices can't read the open platform VID and vice versa?

On the HD disc, there are three different areas: the Burst Cutting Area, the Lead In and the Data Area.
The Burst Cutting Area has the Pre-recorded Media Serial Number and the msb half of the VID, then comes the lead-in area with the second (lsb) half of the VID, followed by the KCD and last the "Partial Media Key Block" (contains the Host Revocation List).

Finally there is the data area. Every device can read the data area without authentication. Apparently, open platform drives don't have the necessary firmware/CDB to read the KCD.

[arnezami]

Just a quicky: for HD DVD the pit length is different for (only) the system lead-in area. Which is (I believe) where the VID and KCD are stored.

And variations in pit length can probably screw up compatability with certain laser systems.

Don't we just love DRM ...

Another little fact: without AACS all discs will start playing about 2-5 secs faster (as in: instantly, instead of sluggish) than without: encryption on the drive's CPU costs time. We just love DRM.

Not to mention perfectly capable HD screens (non HDCP) that won't be allowed full HD res to be displayed pon. Do you want to look bad AACS LA?

Disgusting. Just so you get it: we will not stop until you stop with this crap!! We gladly want to buy your stuff without DRM!

And ooh yeah: managed copy ... its all empty and bad PR as in "ehm, we crippled your system, if you pay us we will un-cripple it again, ehm ... well partially that is" and its DRM-ed of course, not to mention incompatible with BD+.

Regards,

arnezami