Comments for Página do jqr

Comment on AACS’s subset-cover scheme explained by Página do jqr » Blog Archive » AACS processing key found, but scheme not broken

Mon, 28 Sep 2009 13:48:23 +0000

[…] BayAACS processing key found, but scheme not brokenUSB hubs malfunctioning after power surgeAACS’s subset-cover scheme explainedDownloadsOptus UMTS900Optus UMTS data for 2G […]

Comment on USB hubs malfunctioning after power surge by Sarah

Sarah — Thu, 12 Jul 2007 03:15:12 +0000

I had this problem and when I try to fix it like the way you suggested it says I have no problems or anything.

And my USB won’t work at all.
Like the light doesn’t come on.
I’ve tried three computers at work.

And I’m freaking out because everything is on that usb.

Any other ideas please?

Comment on Optus UMTS900 by abc

abc — Wed, 13 Jun 2007 13:15:30 +0000

good initiative, only they should include UMTS900 in the RAN sharing deal with Vodafone.

Comment on AACS’s subset-cover scheme explained by Slightly Confused

Slightly Confused — Wed, 09 May 2007 19:50:41 +0000

On the first part, the problem is that the equations in the diagram don’t match the explanation. KS_7,31 seems like it should equal MID(H(RIGHT(H(T_1)))), not MID(H(RIGHT(H(L_7)))). Expanded for L_7 it should be MID(H(RIGHT(H(RIGHT(H(L_7)))))). Right?

Comment on AACS’s subset-cover scheme explained by admin

admin — Wed, 11 Apr 2007 02:09:04 +0000

Thanks for that comment - regarding the second issue you pointed out, the numbers were wrong (I initially had different tree layout examples in my original sketches). The first part I can’t see any problem with - the image above that block of text shows the subset S7,31. Don’t confuse node numbers on leaf nodes with player numbers.

Comment on AACS’s subset-cover scheme explained by Slightly Confused

Slightly Confused — Tue, 10 Apr 2007 19:56:14 +0000

I follow it until I get to the diagram above the text: “In this example, we start with the label at node 7, hash it, take the right-most 128-bits to get the key for node 15, hash this again, **and take the right-most 128-bits to get the key for node 31, hash this key and the take the middle 128-bits. This is the key for the subset S7,31, which the authority can use to encrypt the media key.**” The diagram appears not to match the quoted portion within **.

I also don’t follow the diagram corresponding to “For the next sub-tree, rooted at 2, we give it the interim-keys derived from node 2’s label key for nodes 6, 15, and 29.” The diagram appears to be nodes 5, 9, and 17.

Comment on AACS processing key found, but scheme not broken by jqr

jqr — Tue, 20 Feb 2007 22:57:38 +0000

This is more complicated. Depending on how the subset-differences exist (based on existing revocations), a single processing key could cover a single player or a huge subset-difference tree of players (potentially the whole tree at the start of the very scheme before players are revoked).

If you read the original research paper here the subset-difference scheme designed by Naor, Naor and Lotspiech (as adapted by AACS) has a mechanism for traitor tracing, given the algorithm enough queries. If the adversary published keys on a website, for example, and these keys were sourced from his player, then the traitor tracing algorithm could, given the traitor enough published keys (log(N) for a single traitor, where N is the number of players in the entire scheme) determine the information to block his player. If he used t players to compromise the system, then he could only publish t.log(N/t) keys before being caught out.

So to summarize, yes, people leaking keys can be caught (have their players blocked) if they leak enough of them.

There is also another mechanism in AACS called “Sequence Keys”, which allows traitors to be identified by the “rips” they release (again, given enough of them).

Comment on AACS’s subset-cover scheme explained by WesleyTech.com

WesleyTech.com — Tue, 20 Feb 2007 17:46:08 +0000

Great post! It definitely helps to explain the AACS(ystem) and the way it functions.

Comment on AACS processing key found, but scheme not broken by Arbaal

Arbaal — Tue, 20 Feb 2007 17:39:10 +0000

Just as a question:

What if the procession key is changed, the WinDVD Player is revoked and somebody find another not-so-well-implementented player (software or even hardware), where he can get the new procession key(s).

Lets say, he will just publishe the procession keys and won’t tell where he get them, is there any way, that the comprimised player can be found? Will there be a effective way for revoking a unknown-player?