Some thoughts about bus key usage with HD-DVD/Blu-Ray

[Fahzuu]

Has anyone ever wondered, what the bus keys are actually used for in AACS protocols?

Isn't it strange, that they are only used for "signing"?

There is this quite important and supposedly secret information, the Volume ID, that is being transferred over the bus totally unencrypted. And the drive and host have to go into some trouble to derive a shared secret bus key - conveniently having the length of 128 bits.
Also AACS requires both host and drive to implement AES code anyway.

But what happens is, that the drive signs this piece of information instead of encrypting it - which would require precisely the same effort.

So:

1. why don't they bother encrypting it?
2. why do they bother signing it? What kind of "attack" can anyone think of, involving a spoofed Volume ID??

We all know, that AACS is not really secure, but I haven't seen them really doing stupid stuff in the specs - apart from this, it seems...

[FoxDisc]

Has anyone ever wondered, what the bus keys are actually used for in AACS protocols?
Isn't it strange, that they are only used for "signing"?
There is this quite important and supposedly secret information, the Volume ID, that is being transferred over the bus totally unencrypted. And the drive and host have to go into some trouble to derive a shared secret bus key - conveniently having the length of 128 bits.
Also AACS requires both host and drive to implement AES code anyway.
But what happens is, that the drive signs this piece of information instead of encrypting it - which would require precisely the same effort.
So:
1. why don't they bother encrypting it?
2. why do they bother signing it? What kind of "attack" can anyone think of, involving a spoofed Volume ID??
We all know, that AACS is not really secure, but I haven't seen them really doing stupid stuff in the specs - apart from this, it seems...

The bus keys you are referring to are used to establish an AACS authenticated session by signing. Once the authenticated session handshake ritual is over, the VID can be passed across the bus to the host. The AACS spec does have a provision for bus encryption, but the drive has to support that, and most drives don't. I suppose they thought that the encryption of the media keys, the encryption of the video data and the encryption of the 32 segments with sequence keys would be sufficient.

[Fahzuu]

The bus keys you are referring to are used to establish an AACS authenticated session by signing.

Just to make sure, we're not talking about 2 different things: to establish an AACS authentication, the bus keys are not required. They sort of "fall out of" the authentication protocol and the don't get used until you actually request a Volume ID, which then is signed with the bus key - for no apparent reason. That's what I don't get.
The authentication itself doesn't need the bus key at all.

[FoxDisc]

Just to make sure, we're not talking about 2 different things: to establish an AACS authentication, the bus keys are not required. They sort of "fall out of" the authentication protocol and the don't get used until you actually request a Volume ID, which then is signed with the bus key - for no apparent reason. That's what I don't get.
The authentication itself doesn't need the bus key at all.
A drive has a drive private key and a drive certificate. A host has a host private key and a host certificate. The drive certificate includes a drive public key, a drive ID and a bus encryption capable bit.

As the specs say, the drive cert has "A Bus Encryption Capable (BEC) bit, where 1 shall be used to indicate that the drive is capable of performing the Bus Encryption that is to be later specified. If the drive is not capable of performing the Bus Encryption, the BEC bit shall be set to 0. When both the drive and PC host are capable of performing the Bus Encryption, the Bus Encryption shall be performed. The details of Bus Encryption will be specified at a future date. Until such time, the BEC bit will be set to 0."

I was referring to this BEC bit and the "to be later specified" type of bus encryption. The whole authentication session protocol seems kind of unimportant in light of the x-box hack. I agree with you that they might have encrypted the VID, but, as I said, I suppose they thought they had enough complexity. Heck, they didn't even choose a very robust VID - they even left it at zero in some cases!

[Fahzuu]

The whole authentication session protocol seems kind of unimportant in light of the x-box hack.

Sure, but the hack only helps HD-DVD users. And chances are good that Blu-ray is going to stay...

I agree with you that they might have encrypted the VID, but, as I said, I suppose they thought they had enough complexity. Heck, they didn't even choose a very robust VID - they even left it at zero in some cases!

The VID is chosen by the studios, isn't it?
And I thought an all-zero VID has only shown up on Relentless Enemies, and that is only because the software didn't recognize, that the whole auth-procedure went wrong (in other words: it's not really a zero VID but a software bug). Or is there really such a thing as (a real) zero-vid?

[arnezami]

Just to make sure, we're not talking about 2 different things: to establish an AACS authentication, the bus keys are not required. They sort of "fall out of" the authentication protocol and the don't get used until you actually request a Volume ID, which then is signed with the bus key - for no apparent reason. That's what I don't get.
The authentication itself doesn't need the bus key at all.
Hi guys ;).

There is a very good reason why the Volume ID is authenticated by the drive (with a MAC). Without this the copy-protection of AACS would be practically broken (without needing any firmware hacks or even keys!).

Let me explain. :)

Right now WinDVD and PowerDVD won't play a movie if the Volume ID is not properly MAC-ed with the Bus Key. This is in fact what prevents anyone from simply copying an encrypted disc and only requiring the Volume ID to do playback.

How?

Suppose for the moment AACS-Auth is implemented but not the VID MAC. What could be done is the following:

Someone could create some sort of disc mounting program that can mount HD discs (eg iso file on hdd). In addition to that it would act like a drive (when it comes to AACS-auth) by sitting between the Software Player (or any other software) and your real drive. In essence: it simply sends the AACS-Auth commands to your drive and sends the results from the drive back to the Player but when the Software Player starts to access files the mounting program gets them from the mounted data (not from a disc in the real drive). There is one exception: when asked for a Volume ID it gets this Volume ID from the mounted disc (which could have been sniffed earlier by somebody). The Software Player does not know this Volume ID is not from a real disc and since it belongs to the mounted dics it can decrypt and play the contents of the mounted disc. In practice the real drive would still need one disc (eg King Kong) so it will actually perform basic AACS-auth but nothing more.

In essence all that is needed is (1) a copy of the encrypted contents of a disc (2) the Volume ID of that disc which can be sniffed (3) one program to install (4) only one real (but random) disc. And AACS would be broken. For all discs. And no keys would ever have to be found (so no Sequence/Device/Host Private/VUK keys etc).

However because the Volume ID is MAC-ed this doesn't work: this is because the mounting program does not know how to MAC the Volume ID (it hasn't got the drive keys) and the drive won't give the Volume ID of the mounted disc of course (only real discs). In other words: the Volume ID MAC is essential to protect from bit-by-bit copy attacks. Because to do the same now (so no usage of keys) everybody who wants to playback a copied disc would need a stealthy hacked drive (not impossible but far less practical) that would simulate a prerecorded disc. This usually requires savvyness and every PC drive type would have to be hacked to make it practical.

So yes. Volume ID authentification using the MAC (with the Bus Key) makes sense.

Why bus encryption isn't implemented is much harder to understand. I was (http://forum.doom9.org/showthread.php?t=121866) and still am baffled by it. The reason given (http://web.archive.org/web/20060604054302/http://www.lotspiech.com/AACS/) is there were some "practicalities". Maybe they simply didn't have enough time. I don't know. But Bus encryption would have made it a lot harder for us to get Volume IDs.

Hope that helped to clear it up. :)

Regards,

arnezami

PS. Yeah I guess I'm back. To be honest I just hate being silent. I just can't stand it. I have been worrying a lot but my thirst of being part of all this is overwhelming that feeling. :)

[Pelican9]

PS. Yeah I guess I'm back. To be honest I just hate being silent. I just can't stand it. I have been worrying a lot but my thirst of being part of all this is overwelming that feeling. :)

WELCOME BACK! :)

[awhitehead]

The VID is chosen by the studios, isn't it?
And I thought an all-zero VID has only shown up on Relentless Enemies, and that is only because the software didn't recognize, that the whole auth-procedure went wrong (in other words: it's not really a zero VID but a software bug). Or is there really such a thing as (a real) zero-vid?

I don't believe that to be the case. I believe that the studio sends a DLT with the image to the replicator (I could double-check what Apple Final Cut Studio does, since it supports HD-DVD mastering and supports formats commonly understood by replicators), and replicator in turn generates the disc by mangling the key provided by AACS LA and a VID that they pick, and in turn generating the master.

That's why there are VIDs such as dates, names of the movies, etc. It seems like the software replicators use is slightly different and obtains it's entropy for the VID from different places - project names, current date and time, /dev/random, etc. But there actually are a number of distinct "flavors" of VID, that seem to indicate which replicator was used for which disc.

As for Relentless Enemies.... If you read the BCA on it, you get 4000011520072036 for the first half of the VID. However reading the VID using tools that properly authenticate would generate 16 bytes of 00s. I believe that it's a mastering problem, but who knows? Maybe it's a new means of preventing folks with PCs running the disc. It plays fine on a stand-alone, though.

VID for Relentless Enemies is actually 40000115200720362020202020200000 if I recall correctly (This is all done from memory, and my memory on numbers is not all that good :-)

P.S. arnezami: We missed you! Glad to see you back!

[Kiriakos]

PS. Yeah I guess I'm back. To be honest I just hate being silent. I just can't stand it. I have been worrying a lot but my thirst of being part of all this is overwelming that feeling. :)

Realy the top moment of my day. :thanks: :)

[Revgen]

Hi guys ;).

Well, now that you're back, you are herefore appointed as the unofficial moderator of the decryption forum. :p

Blutach was driven crazy by all of us HD-DVD freaks.:)

But seriously, we're all glad you're back. Just be cautious and you'll be okay.