Updated Draft for AACS Command Set

Henry Gabryjelski henrygab at windows.microsoft.com
Mon Jul 11 10:46:11 PDT 2005

* From the T10 Reflector (t10 at t10.org), posted by:
* "Henry Gabryjelski" <henrygab at windows.microsoft.com>
Ishihara-san, MMC members,

We are actively reviewing these changes.  Of particular concern is the
following two items:

1) Allowing drives to support only a single AGID.  For DVD-ROM, this was
not noticable due to the exclusive and read-only nature of the media.
For AACS, this may become a problem due to the read-write nature of the
media.  This requires some additional study here within Microsoft, to
ensure the best customer experience is possible.

2) Preventing reads of the data.  I understand that this modification
was requested to prevent a title key attack, where the title key for an
encrypted film is provided via unauthorized means to decrypt the file.
I initially (in the first two hours or so) did not see significant
difficulty with this, but further thought has brought up some concerns:

This modification seems to add drive cost and limit reading speed due to
the necessary application of "encryption" of portions of sectors.  This
modification of sector data is further difficult as it will cause many
automated drive integrity tools(*) to incorrectly flag errors on these
sectors.  This modification will restrict the capability of backing up
and restoring the encrypted movie content, further restricting customer

I would like to challenge the benefit of encrypting the "movie" (or
other protected content -- but I will use the term movie) sectors.  For
example, if a title key for a movie has been found in the clear, then
the entirety of the contents of the movie are also, by definition,
available in the clear.  Once the content has become available on the
"dark net", then it is available.  Preventing the encrypted movie
sectors from being read from the media does not seem to add protection,
but simply adds another restriction for legitimate users of the movie.

With the previous versions of the specification, users would be able to
move their encrypted movies via defrag operations, recovery would be
possible if a sector was going bad without special "AACS-aware"
utilities, etc.  With the current modifications, users are now
prohibited from using many common tools on their movies (and indeed the
entire media) due to these restrictions.

It is possible that these changes will be acceptable, but significant
additional thought is required to be sure.  It is also possible that
another method that still allows the customer scenarios (and does not
put additional overhead on the file system, os, and other utilities)
will be possible.  As you know, MMC requires proposals to be provided
well in advance of the meetings in order to enable proper consideration
of the changes for all parties, as well as enable companies to consider
if attendance at a particular meeting is critical.

I would like to suggest that voting for the addition of these changes
into the MMC (and Mt. Fuji) specifications be delayed, to allow the
extra time necessary to fully understand the impact of these changes.


Henry Gabryjelski

(*) Driver verifier (verifier.exe) in Windows has such a tool that any
client may enable.  Also, some bus trace tools also enable this advanced
functionality for read-only devices.


-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Atsushi Ishihara
Sent: Sunday, July 10, 2005 6:24 PM
To: mtfuji5 at avc-pioneer.com; T10 at t10.org
Cc: atsushi.ishihara at toshiba.co.jp
Subject: Updated Draft for AACS Command Set

Because the original sending failed in an error, I am resending this.

Dear All,

I have placed updated drafts for AACS command set on the Mt. Fuji FTP 
site. Please look in the following URL.


The drafts reflect the result of AACS SWG meeting held on July 5th. The 
drafts are prepared in the form of Mt. Fuji specifications and each 
drafts are in both clean version and redlined version. I would like to 
discuss these drafts and conclude them at the Mt. Fuji meeting tomorrow.

Best Regards,
Atsushi Ishihara, Toshiba
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list