Was a mistake made in the design of AACS?

Perry E. Metzger perry at piermont.com
Wed May 2 15:07:30 EDT 2007


Expanding my last message to make it clearer:

Schemes like the AACS one work quite well for satellite TV broadcast
protection. In such systems, one's goal is to disable the units owned
by rogue subscribers, but the only "inventory" that one might ruin by
a key invalidation is a bit of electromagnetic radiation in transit
from the broadcast site to the subscribers. Little is lost by
performing a revocation.

An ongoing business relationship exists with the legitimate
subscribers as well, so they can receive updates in the form of
hardware tokens that are difficult to reverse engineer "quickly
enough". Further, the users of unauthorized decoders are in a bit of a
bind -- they cannot retrieve last months' broadcasts while waiting for
new keys, so if they want entertainment now they need to have a
continuous supply of keys fed in real time.

In the HD-DVD/Blu Ray case, the model is very different. End users of
hardware players have no ongoing relationship with the provider, so
one cannot be guaranteed the ability to update. All old disks sold can
be compromised, and they constitute a substantial risk, as does the
actual inventory of disks waiting to be sold. Additional economic
hardship comes from the fact that there is non-zero effort involved in
sending new masters to production houses and in tracking dead
inventory.

As I noted, in the direct broadcast satellite case "slow leaks" of keys
over extended periods of time are not of much use to the end users and
are not of much damage to the system owners, but in the AACS case
"slow leaks" are actually exceptionally damaging. Were the bad guys to
release just one key every couple of months it would effectively
destroy the system.

There is also the issue of differing threat models. In a broadcast
system, you are attempting to assure that people watching the real
time broadcast are paying you money. In the high def video disk case,
you have several quite different goals from the broadcast case. One is
to enforce region encoding so that you can charge U.S. customers a
large multiple of what you charge, say, a Chinese customer for exactly
the same material. The second is to prevent people from retrieving the
content in a form they can send to their friends over the internet. A
third goal is to keep customers from being able to use content in
unplanned ways so you can up-sell them to a newer format later
on. (Note that the DRM scheme does *not* prevent actual commercial
piracy of disks, since pirates can simply press bit for bit identical
disks.)

Goals one through three are all failures even if key data leaks only
quite slowly to the public. You will be just as interested in
preventing people from watching different region HD-DVDs that are
three months old as you will in preventing them from watching ones
that are only days old. You will be just as interested in preventing
people from uploading the contents of Blu Ray disks that are a few
months old as you will in preventing uploads that are from brand new
releases. On part three, the failure would be quite complete --
collectors of HD discs will be able to transfer their old discs to
their new UltraVideoPseudoPods in ten years, thus eliminating the
lucrative business of selling them content they have previously bought
in a new format.

My feeling, then, is that the entire HD protection scheme was a
miscalculation. Methods like this worked just fine for satellite TV,
and they were then applied without sufficient thinking about threat
models to a new domain where things are quite different.

This seems to me to be, yet again, an instance where failure to
consider threat models is a major cause of security failure. It is not
enough to throw clever algorithms at things -- you have to consider
what it is that you are trying to defend against specifically, and how
those algorithms will lead to the specific security goals.

I will again solicit suggestions about "optimal" strategies both for
the attacker and defender for the AACS system -- I think we can learn
a lot by thinking about it. It would be especially interesting if
there were modifications of the AACS system that would be more hardy
against "economic attacks" -- can you design the system so that slow
key revelation is not an economic disaster while still maintaining an
offline delivery model with offline players entirely in the enemy's
control? I don't think you can, but it would be very interesting to
consider the problem in detail.

-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list