A possible solution to prevent AACS device key revocation

[ShadowFlare]

Earlier today, an idea came to my mind for a way to potentially prevent AACS device keys from being revoked because of being used for obtaining volume keys. For this to work, there would first need to be a requirement of having a program to decrypt the volume keys by having device keys and that would not include any actual device keys with itself.

Assuming that such a program is created, that it is possible to obtain a device key through some means, and that the file containing the encrypted volume keys is not too large for timely transfer over the internet, it would be possible to have a web site running on a private web server that would have a script that would accept an upload of the file containing the encrypted volume key(s) and then give back the decrypted volume key.

When the script receives the file with the encrypted volume keys, it would then run the program to decrypt the volume key with a private, non-disclosed device key stored on the web server in a location not accessible through the web site. After decrypting the volume key, it could be displayed on the resulting page and possibly stored in a database as well.

This way the device key used to obtain the volume key is never exposed, and thus it is not known which to revoke.

[diogen]

This has been discussed in Felton's series here (http://www.freedom-to-tinker.com/?p=1107):
"As it turns out, the designers of AACS anticipated decryption oracles, so the system includes a way to track down and blacklist the device keys used to operate them. This process is called “traitor tracing,”..."

Diogen.

[The_ByteMaster]

In a later post (http://www.freedom-to-tinker.com/?p=1110), Ed Felten also said this:

things get interesting if the attackers get Variant Keys from many different players and then combine them cleverly to try to avoid being identified; there’s a whole theory considering how well such attacks will work.

Another thing is that once a 'working' player is compromised, all the content that has been released (and is about to be released) thus far (and hasn't been revoked) is compromised.

So what if one is willing to "sacrifice" a player? Perhaps just a software player... but maybe a hardware player that sat on a guy's workbench for a few hours before it gave up its secrets and got returned to the store. [Let's not get into the morality of this, we all know it's wrong.]

You may have to wait a couple of months to copy your recently bought HDDVDs/BDs to your server, but eventually you should be able to. We'll have to see how fast revokation works, but perhaps we can get away with a grand total of say 3-4 compromised players per year.

[ShadowFlare]

This has been discussed in Felton's series here (http://www.freedom-to-tinker.com/?p=1107):
"As it turns out, the designers of AACS anticipated decryption oracles, so the system includes a way to track down and blacklist the device keys used to operate them. This process is called “traitor tracing,”..."

Diogen.
I thought of that exact scenario around 30 minutes or an hour after I first started this thread. That attack could easily be countered by having a system that requires logging in when uploading the encrypted keys and where only "trusted users" may get the decrypted volume key(s) until they have been verified to match with an actual existing disc. If the decrypted keys do not match an actual disc, the resulting decrypted volume key will not be available to users who are not trusted users.

In this scenario, "trusted users" would be those who the administrator has specifically given access to unverified volume keys and possibly also those who have submitted enough new keys that have been verified. Those who do become "trusted users" and upload fakes would face having their access privileges to unverified volume keys either temporarily or permanently revoked, depending on how many times they try it.

Of course, when they start using those sequence keys as mentioned in that next part of Felten's series, more will need to be done than just this. This particular scenario is likely the very reason they thought up the sequence key idea.

[noclip]

AACS-LA uses Volume Variant Unique keys to discover which player was compromised to create a certain copy. Each player decodes protected content slightly differently, so it's easy for them to tell.

[ShadowFlare]

Yes, I am sure they will start using that eventually; however, based on the information The_ByteMaster linked to, I was under the impression that they are currently not using that part of the spec.

[Galileo2000]

Yes, I am sure they will start using that eventually; however, based on the information The_ByteMaster linked to, I was under the impression that they are currently not using that part of the spec.

AFAIK, this feature is not on yet, and will not be on for at least a year.

[awhitehead]

Resurrecting an old thread, just because it seems to be the one with the most apropriate subject. Please forgive me if it's offtopic.

I was playing with the firmware update image for Samsung BDP-1000 BD player, that I downloaded off of http://www.1080x1920.net/

I don't own the player itself, but it was a 10 meg download, I was bored, etc. Inside the .zip file there is an ISO image, that can be mounted, and that contains 3 files:

hostname:/Volumes/BDP1000[08:05 PM]$ ls -la
total 107396
drwxr-xr-x 1 root admin 2048 Apr 27 2006 .
drwxrwxrwt 7 root admin 238 Mar 17 18:54 ..
-rwxr-xr-x 1 root admin 4194304 Sep 29 22:10 060929_01_R100.RUF
-rwxr-xr-x 1 root admin 50331648 Oct 10 21:59 061011_01_Poseidon.RUF
-rwxr-xr-x 1 root admin 458752 Sep 29 02:40 BD1F929F.SSE
hostname:/Volumes/BDP1000[08:05 PM]$


When looking for ASCII string sequences in the 061011_01_Poseidon.RUF, I see that the player firmware explicitly checks for the following files:

hostname:/Volumes/BDP1000[08:10 PM]$ strings 061011_01_Poseidon.RUF | grep ^\/UDFATAPI | sort -u
/UDFATAPI/AACS/AACS_av/Binding_Nonce.dat
/UDFATAPI/AACS/AACS_av/CPSUnit00001.cci
/UDFATAPI/AACS/AACS_av/Content000.cer
/UDFATAPI/AACS/AACS_av/Content001.cer
/UDFATAPI/AACS/AACS_av/ContentHash000.tbl
/UDFATAPI/AACS/AACS_av/ContentHash001.tbl
/UDFATAPI/AACS/AACS_av/ContentRevocation.lst
/UDFATAPI/AACS/AACS_av/Device_Binding_ID.dat
/UDFATAPI/AACS/AACS_av/Flash_ContentRevocation.lst
/UDFATAPI/AACS/AACS_av/Flash_DeviceKeys.dat
/UDFATAPI/AACS/AACS_av/Flash_PublicKey.dat
/UDFATAPI/AACS/AACS_av/Flash_SequenceKeys.dat
/UDFATAPI/AACS/AACS_av/KCD.dat
/UDFATAPI/AACS/AACS_av/MediaID.dat
/UDFATAPI/AACS/AACS_av/PMSN.dat
/UDFATAPI/AACS/AACS_av/SKB1.dat
/UDFATAPI/AACS/AACS_av/Segment_Key.inf
/UDFATAPI/AACS/AACS_av/Unit_Key_RW.inf
/UDFATAPI/AACS/AACS_av/VolumeID.dat
/UDFATAPI/AACS/AACS_mv/Binding_Nonce.dat
/UDFATAPI/AACS/AACS_mv/CPSUnit00001.cci
/UDFATAPI/AACS/AACS_mv/Content000.cer
/UDFATAPI/AACS/AACS_mv/Content001.cer
/UDFATAPI/AACS/AACS_mv/ContentHash000.tbl
/UDFATAPI/AACS/AACS_mv/ContentHash001.tbl
/UDFATAPI/AACS/AACS_mv/ContentRevocation.lst
/UDFATAPI/AACS/AACS_mv/Device_Binding_ID.dat
/UDFATAPI/AACS/AACS_mv/Flash_ContentRevocation.lst
/UDFATAPI/AACS/AACS_mv/Flash_DeviceKeys.dat
/UDFATAPI/AACS/AACS_mv/Flash_PublicKey.dat
/UDFATAPI/AACS/AACS_mv/Flash_SequenceKeys.dat
/UDFATAPI/AACS/AACS_mv/KCD.dat
/UDFATAPI/AACS/AACS_mv/MediaID.dat
/UDFATAPI/AACS/AACS_mv/PMSN.dat
/UDFATAPI/AACS/AACS_mv/SKB1.dat
/UDFATAPI/AACS/AACS_mv/Segment_Key.inf
/UDFATAPI/AACS/AACS_mv/Unit_Key_RW.inf
/UDFATAPI/AACS/AACS_mv/VolumeID.dat
/UDFATAPI/AACS/Binding_Nonce.dat
/UDFATAPI/AACS/CPSUnit00001.cci
/UDFATAPI/AACS/Content000.cer
/UDFATAPI/AACS/Content001.cer
/UDFATAPI/AACS/ContentHash000.tbl
/UDFATAPI/AACS/ContentHash001.tbl
/UDFATAPI/AACS/ContentRevocation.lst
[...]
/UDFATAPI/AACS/Device_Binding_ID.dat
/UDFATAPI/AACS/Flash_ContentRevocation.lst
/UDFATAPI/AACS/Flash_DeviceKeys.dat
/UDFATAPI/AACS/Flash_MKB.inf
/UDFATAPI/AACS/Flash_PublicKey.dat
/UDFATAPI/AACS/Flash_SequenceKeys.inf
/UDFATAPI/AACS/KCD.dat
/UDFATAPI/AACS/MKB_RO.inf
/UDFATAPI/AACS/MKB_RW.inf
/UDFATAPI/AACS/MediaID.dat
/UDFATAPI/AACS/PMSN.dat
/UDFATAPI/AACS/SKB1.dat
/UDFATAPI/AACS/Segment_Key.inf
/UDFATAPI/AACS/Unit_Key_RO.inf
/UDFATAPI/AACS/VolumeID.dat
[...]


some of which seem to be explicitly related to key revocation.
(kernel boots with what seems like these boot arguments:
-Xverify:all -Xms8m -Xss64K -Djava.home=/ramClass -Dudf.root=/UDFATAPI -Xbootclasspath=/ramClass/crypto.jar samsung.jam.Main so UDF volumes get mounted and accessed internally as /UDFATAPI/<stuff>)

While most of this seems to be duplicates of the data in AACS tree on a Blu-Ray disk, I don't think there is anything with \AACS\Flash_ContentRevocation.lst or \AACS\ContentRevocation.lst out yet.

So anyone with any interest on what a player actually checks for, when dealing with content revocation, can probably repeat my steps, and do some further investigation.

P.S. BDP-1000 seems to be ARM based, and runs firmware based on VxWorks 5.1. It's been years since I did anything serious with VxWorks, and also years since I played around with ARM7 + THUMB based cores (in my case SA110s), so I am not all that keen to continue with real reverse engineering.

P.P.S. If you are keen on extracting private keys from a standalone player, disassembling and tracing function EncryptedPrivateKeyInfo is probably as good a place to start as any.