wraggster
January 3rd, 2007, 12:09
via doom9 (http://forum.doom9.org/showthread.php?p=924730#post924730)
Heres what he said:
I spent the last few days reading a lot of articles on BackupHDDVD, reading a lot of people's post/comments on various websites.
This is the time to set the record straight about this new tool and what the impacts are.
First I need to clarify some points.
Revocation:
In the AACS system, there is 4 types of revocation:
Drive revocation
Host revocation
Device revocation (with MKB)
Content revocation
There is no such thing as "title key revocation" and "volume key revocation"
-------------
Now, here is a list of affirmations I have seen lately.
Affirmation 1: You did not break AACS, just the player
My comment: I did not break AACS, but I find a way to decrypt movies and I have bypassed all the revocation system.
Not that bad...
Affirmation 2: The BackupHDDVD circumvention tool won't last long
My comment: As long as insecure players will exist, it will last...
And insecure players will always exist, in fact you can extract keys from any player! Some players are just easier to extract the key from. Being lazy, I prefer to extract keys from an insecure player than a secure one.
And the AACS spec says "Device keys must be protected!" but they did not said that about volume key, fatal mistake!
Affirmation 3: The keys can easily be revoked.
My comment: What keys are you talking about? As I stated before, there is no such thing as "title key revocation" and "volume key revocation". If someone publishes only volume keys, there is no way to know from which player these keys where extracted from, making the revocation system useless. They can do content revocation, but to revoke what? All movies before 2007? They can do player revocation, so I will just change the player I'm using, big deal...
So what is the AACS revocation system good at? It is good for that scenario:
Someone post on the net, a tool that do the complete decryption automatically. Off course the program use stolen device keys from an Official player. They (AACS and friends) will eventually get their hands on this program, look at the device keys and revoke them. Making that player unable to play new titles. But the author of this program can pre-extract a bunch of devices keys from different players and release them, one at the time, when the previous one have been blacklisted. The AACS spec says "Device keys must be protected!" so I suppose they put more effort in protecting these keys then the volume key in memory.
Affirmation 4: BackupHDDVD is nothing, only one person out of a million have the technical skills to extract keys.
My comment: BackupHDDVD is a proof of concept.
Picture this:
Few skilled persons can do massive volume key extraction, and send the keys to a central server on the internet. Then, they create an easy to use decryption program, with a nice GUI that do online key recovery. That way, my father and your father can backup movies.
Or they can send the keydb.cfg file on P2P networks (BitTorrent, E-Mule, etc..)
See the problem now?
Affirmation 5: You can extract keys from software player on personal computer but not on hardware player.
My comment: It's easier to extract keys from software player, but it also possible to extract keys from hardware player (the set-top box in your living room!)
Conclusion:
The attack I describe in "Affirmation 4", is not here yet, but it's coming. So I give MPAA and AACSLA a head start. Start to think what you can do about that.
To totally block this attack, they need to put different keys on every disk! Now, they only have different keys for different movies. I don't know about the manufacturing process of the disk. This solution may not be possible.
The best they can do, is doing shorter manufacturing run of a particular movie, so it would be difficult to get your hand on every "pressing" of a movie.
When they design AACS, they assume people will look for the device keys. I don't care about device keys. I do care about volume key. Having the device keys mean that you have to re-implements all the complex crypto and do the full AACS process.
I leave all this dirty job to the player and recover only the volume key.
There is 3 important things in cryptography:
1-Private key protection
2-Private key protection
3-Private key protection
Did I break AACS? I don't know. What do you think?
I'm not going to work on this anymore, I'm taking a vacation!
Ok, here it is, BackupHDDVD V1.00!
What's new in this version?
- Volume key support
- Partial resume of an interrupted decryption session
- New file format and file name for key database file.
The key database file is now KEYDB.cfg
Heres what he said:
I spent the last few days reading a lot of articles on BackupHDDVD, reading a lot of people's post/comments on various websites.
This is the time to set the record straight about this new tool and what the impacts are.
First I need to clarify some points.
Revocation:
In the AACS system, there is 4 types of revocation:
Drive revocation
Host revocation
Device revocation (with MKB)
Content revocation
There is no such thing as "title key revocation" and "volume key revocation"
-------------
Now, here is a list of affirmations I have seen lately.
Affirmation 1: You did not break AACS, just the player
My comment: I did not break AACS, but I find a way to decrypt movies and I have bypassed all the revocation system.
Not that bad...
Affirmation 2: The BackupHDDVD circumvention tool won't last long
My comment: As long as insecure players will exist, it will last...
And insecure players will always exist, in fact you can extract keys from any player! Some players are just easier to extract the key from. Being lazy, I prefer to extract keys from an insecure player than a secure one.
And the AACS spec says "Device keys must be protected!" but they did not said that about volume key, fatal mistake!
Affirmation 3: The keys can easily be revoked.
My comment: What keys are you talking about? As I stated before, there is no such thing as "title key revocation" and "volume key revocation". If someone publishes only volume keys, there is no way to know from which player these keys where extracted from, making the revocation system useless. They can do content revocation, but to revoke what? All movies before 2007? They can do player revocation, so I will just change the player I'm using, big deal...
So what is the AACS revocation system good at? It is good for that scenario:
Someone post on the net, a tool that do the complete decryption automatically. Off course the program use stolen device keys from an Official player. They (AACS and friends) will eventually get their hands on this program, look at the device keys and revoke them. Making that player unable to play new titles. But the author of this program can pre-extract a bunch of devices keys from different players and release them, one at the time, when the previous one have been blacklisted. The AACS spec says "Device keys must be protected!" so I suppose they put more effort in protecting these keys then the volume key in memory.
Affirmation 4: BackupHDDVD is nothing, only one person out of a million have the technical skills to extract keys.
My comment: BackupHDDVD is a proof of concept.
Picture this:
Few skilled persons can do massive volume key extraction, and send the keys to a central server on the internet. Then, they create an easy to use decryption program, with a nice GUI that do online key recovery. That way, my father and your father can backup movies.
Or they can send the keydb.cfg file on P2P networks (BitTorrent, E-Mule, etc..)
See the problem now?
Affirmation 5: You can extract keys from software player on personal computer but not on hardware player.
My comment: It's easier to extract keys from software player, but it also possible to extract keys from hardware player (the set-top box in your living room!)
Conclusion:
The attack I describe in "Affirmation 4", is not here yet, but it's coming. So I give MPAA and AACSLA a head start. Start to think what you can do about that.
To totally block this attack, they need to put different keys on every disk! Now, they only have different keys for different movies. I don't know about the manufacturing process of the disk. This solution may not be possible.
The best they can do, is doing shorter manufacturing run of a particular movie, so it would be difficult to get your hand on every "pressing" of a movie.
When they design AACS, they assume people will look for the device keys. I don't care about device keys. I do care about volume key. Having the device keys mean that you have to re-implements all the complex crypto and do the full AACS process.
I leave all this dirty job to the player and recover only the volume key.
There is 3 important things in cryptography:
1-Private key protection
2-Private key protection
3-Private key protection
Did I break AACS? I don't know. What do you think?
I'm not going to work on this anymore, I'm taking a vacation!
Ok, here it is, BackupHDDVD V1.00!
What's new in this version?
- Volume key support
- Partial resume of an interrupted decryption session
- New file format and file name for key database file.
The key database file is now KEYDB.cfg