Validating Volume Unique Key

[evdberg]

I don't think this was already done, so I made a small tool (PC only) to check whether a VUK (Volume Unique Key) is valid for a disk.

Usage: ValidateVUK <sourcefolder> <vuk>

The <sourcefolder> is either the drive with the original (for instance e: ) or a folder on your harddrive with the HD-DVD contents.

[melakai]

The attachment doesn't contain the source, so I'm curious:

How are you "validating" it ?

[evdberg]

I am using the method that is already discussed on this forum, checking the TKF_CMAC ... I just wondered why nobody had implemented it in the meantime.

[SBeaver]

I am using the method that is already discussed on this forum, checking the TKF_CMAC ... I just wondered why nobody had implemented it in the meantime.

How long would you say it takes to make the validation?
I'm guessing long enough to make it useless for bruteforcing, but I'm still curious.

[evdberg]

How long would you say it takes to make the validation?

About the same time to decrypt one block of the stream data.

I'm guessing long enough to make it useless for bruteforcing, but I'm still curious.

AES is too strong for bruteforce, but this method is very suitable for plain-text-attack (so if you have a limited set of possible keys).

[Nutrition24]

I am using the method that is already discussed on this forum, checking the TKF_CMAC ... I just wondered why nobody had implemented it in the meantime.

I did ;) It was already implemented in the BackupHDDVD-GUI version. (But it was not yet available as a separate tool).

[SBeaver]

About the same time to decrypt one block of the stream data.



AES is too strong for bruteforce, but this method is very suitable for plain-text-attack (so if you have a limited set of possible keys).

That's what I was thinking.
I mean maybe somewhere down the line someone finds out that the volume unique keys all follow some pattern or are kept within some specific range which could make bruteforce possible, and maybe the player/host keys follow some particular pattern as well.
If a worldwide joint-venture put up some kind of distributed computing network á la prime95 wouldn't it be possible to bruteforce and get at least a few player/host keys?
There must be a very large number of player keys available so that they can keep all manufacturers in ample supply for many years to come, probably millions of keys just to be safe.
If the revokation system doesnt work though something like this would be useless.
On the other hand if they can make new discs where the compromised keys no longer work (I don't mean through a revokation list) then this might be worth a shot.
I could try to make some kind of guesstimate on the probabillity of finding a key, but I don't have enough data right now and maybe it isn't necessary anyway.

Some stuff worth reading I just came across: http://forum.doom9.org/showthread.php?t=121866

[noisehole]

while this cmac/vu method works nicely for hd dvds, is there any way to do this for blueray discs?

i searched the aacs specs, but couldnt find any similar validation value. there are tons of hashes, but if i understood correctly those are just for validating the files itself, not if the decryption key is valid.

[evdberg]

In general you can use any hash or MAC to validate the key used to calculate that specific hash or MAC. In this case I can use the MAC of the titlekeyfile to validate the VUK, because the VUK is used to calculate this MAC. So for BluRay you have to look for something similar: a hash or MAC that is calculated using the VUK.

[noisehole]

thats my point: every hash on bd is calculated as

Hash_Value = [SHA-1(Hash_Unit)]lsb_64

theres no vuk involved (unless i missed some value)