Pseudorandom processing key search, a joke?

[880]

I am very bored and want some Processing Keys, so I began searching Japanese websites. I stumbled across MKB full and MKB random (http://ysk.orz.hm/BD/AACSMKBSEARCH/) (version 0.2 by taku). They appear to generate possible Processing Keys and test them against a Blu-ray.

But this is madness! Unless this program is using good guesses, it will never find the key! There are 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys (340 undecillion). Even if it took 1ns to check, these programs will run for ten sextillion years. Does 'taku' know something I do not?

:confused: :eek:

[setarip_old]

@880

Hi!

The very obvious question - Have you tried it?

[880]

Yes. I let it run for ten seconds. It did not find the key to my MKB v12 disc.

[burfadel]

How does the disk player play the disk in the first place? surely it can't be that difficult for an expert to create a 'reader' for the key (hasn't that already been done anyway)?

[LoRd_MuldeR]

Nope, the player doesn't read the key from the disc. At least not directly ;)

The player can derive the disc key by using data read from the disc (some of that data can only be read with a valid certificate or a hacked drive) combined with secret information that never leave the player!

So even if you manage to read all the required data from the disc, that data will be useless for you, unless you also have the secret data that the player "knows".

As far as I know, so far the success in hacking AACS was always done by stealing the secrets from a "weak" software player. However AACS has a system to blacklist "broken" players on future disc releases.

Therefore "fresh" keys must be leaked for each new disc generation. Of course the player developers try to make it harder to "extract" the secret keys with each update -> cat-and-mouse game :D

For details:
http://forum.doom9.org/showthread.php?t=122363

[TomZ]

I am very bored and want some Processing Keys, so I began searching Japanese websites. I stumbled across MKB full and MKB random (http://ysk.orz.hm/BD/AACSMKBSEARCH/) (version 0.2 by taku). They appear to generate possible Processing Keys and test them against a Blu-ray.

But this is madness! Unless this program is using good guesses, it will never find the key! There are 340,282,366,920,938,463,463,374,607,431,768,211,456 possible keys (340 undecillion). Even if it took 1ns to check, these programs will run for ten sextillion years. Does 'taku' know something I do not?

:confused: :eek:

So, what we need, is "only" 340 undecillion computers and it will take less than 1s to find keys :)

[HWK]

So, what we need, is "only" 340 undecillion computers and it will take less than 1s to find keys :)

And lot of megawatts of electricity. :D

[Wombler]

Or a quantum computer! :)


Wombler

[Dark Shikari]

Or a quantum computer! :)


WomblerNot enough. A quantum computer only reduces the cost of a linear search from O(n) to O(sqrt(n)), which effectively reduces the key size by half. A 64-bit keyspace is still enormous.

[Wombler]

Not enough. A quantum computer only reduces the cost of a linear search from O(n) to O(sqrt(n)), which effectively reduces the key size by half. A 64-bit keyspace is still enormous.

Pardon my ignorance here but how come you can't check all the possible keys simultaneously?


Wombler

[Guest]

Read about Grover's search algorithm:

http://www.quantiki.org/wiki/index.php/Grover's_search_algorithm

[Wombler]

Thanks for that.

So it seems it's not possible to present all the possible keys at once even if you have enough qubits.

Odd that, but then everything about quantum physics is counterintuitive.

[Guest]

Odd that, but then everything about quatum physics is counterintuitive.

Only when incorrectly interpreted.

[bazzerr]

How about if the program was modified to include a starting address code query and then we could spread the load amongst everyone - granted we'd still require a shedload of people / computers and time .

[LoRd_MuldeR]

How about if the program was modified to include a starting address code query and then we could spread the load amongst everyone - granted we'd still require a shedload of people / computers and time .

Even if every computer on earth did participate, this still would take far too long...

[cRTrn13]

But using a randomized search pattern, we could strike it lucky (ignoring the large statistical improbability). Maybe it's worth donating our spare flops anyway...

[kreet]

the key space is 128 bits, not 64.

bazzerr: processing keys are randomly selected using a strong true-rng. there is no 'starting address code'. you would need to attempt each and every one of the 340282366920938463463374607431768211456 keys.

(you could probably eliminate the values of all known processing keys for previous mkbs, and all known revoked device-keys, but that only cuts a hundred or so off that number. hardly a difference ;)

in addition the operation necessary to verify that a key is good is two AES operations. 1 to generate a volume-unique key from the processing key and volume-identifier, and 1 to generate a title key from the volume-unique key and the encrypted title key.

a heavily optimized application could probably get around 5000-10000 tests per second. lets be generous and say we can squeeze out 10000 seconds. wed still need 34028236692093846346337460743176821 seconds!

thats 486117667029 times the number of stars in the universe!

as for your distribution idea. lets say there are 6.5 billion people on earth. lets say half (gross overestimate!) of those have computers, and that each of those computers can achieve our 10000 attempts per second (well round it up to 4 billion, to ease the math):

>>> ((2 ** 128)/10000)/(4 * (10**9))
8507059173023461586584365L

thats still a lot of seconds ;)

bottom line: brute forcing the processing key is always a joke!

[cRTrn13]

Well a sperm whale was suddenly and instantly called into existence moments before hitting the ground, but that didn't stop Douglas Adams from writing a book about it! :)

@kreet
10000 tests per second is generous anyway. :)

Maybe a parallel FPGA array could handle it?? Could pipe through a lot more than 10000 tests/sec...

[kreet]

cRTrn13:

(wow! thats hard to type!)

even with dedicated hardware it would be practically impossible. sfaik, the biggest key cracked with fpgas was a DES 56 bit key. even that takes a few days, and hundreds of thousands of dollars. remember that each additional bit in the key DOUBLES the time needed to search the space.

"The amount of time required to break a 128-bit key is also daunting. Each of the 2128 (340,282,366,920,938,463,463,374,607,431,768,211,456) possibilities must be checked. A device that could check a billion billion keys (1018) per second would still require about 1013 years to exhaust the key space. This is a thousand times longer than the age of the universe, which is about 13,000,000,000 () years."

http://en.wikipedia.org/wiki/Brute_force_attack <-- end of story

[NeonMan]

Has anyone reviewed the code to see what it does?

processing keys are randomly selected using a strong true-rng. there is no 'starting address code'. you would need to attempt each and every one of the 340282366920938463463374607431768211456 keys.

It wouldn't be the first time a DRM used a shortened keyspace and a flawed PRNG (CSS anyone?)

[pynux]

i go out of home for the week end , just for fun i have launch the randown for a mkbv12
if it's find the key i play euromillions or LOTO ^^

[kreet]

NeonMan:

the prng specified as part of the aacs spec is very strong. the root keys in the subset-difference tree (from which all processing and device keys are derived in a cryptographically strong manner) were randomly selected using a true RNG. there is no shortened keyspace here.

[NeonMan]

@Kreet:
I've only taken a look at the specs so I missed/forgot that detail :thanks:

[Ajax_Undone]

http://www.copacobana.org/docs.html

Anyone... Suppose that a device was created for (A load of money) That could process that amount of keys.

[880]

Read your own link
breaking RSA or elliptic curves with parameter lengths used in most practical applications is out of reach with COPACOBANA

[PatlaborForce]

the key space is 128 bits, not 64.

No one said it was 64-bit. What DS said was that one could reduce the complexity to around a 64-bit space with a quantum computer doing a linear search.

[kreet]

oh right. quantum computer. ill just have my Knight Industries vehicle do it in its spare cycles ;)