Updated Draft for AACS Command Set
henrygab at windows.microsoft.com
Mon Jul 11 12:20:04 PDT 2005
* From the T10 Reflector (t10 at t10.org), posted by:
* "Henry Gabryjelski" <henrygab at windows.microsoft.com>
1) We are still looking into this issue. Unfortunately, we have no
conclusion at this time, and are glad to understand that it will be
possible to increase above the value of one if needed. For the current
proposal, I think a single AGID is acceptable.
2) You are correct. I am very sorry for my mistake. Please excuse me
for my misunderstanding.
I find no difficulties with the current proposed changes. Please vote
on these as needed. :)
From: owner-mtfuji5 at avc-pioneer.com
[mailto:owner-mtfuji5 at avc-pioneer.com] On Behalf Of Atsushi Ishihara
Sent: Monday, July 11, 2005 11:20 AM
To: mtfuji5 at avc-pioneer.com
Cc: T10 at t10.org; David Walp
Subject: Re: Updated Draft for AACS Command Set
Thank you for your comment.
I understand your first comment regarding the number of AGID supported
by drive. If it is understood by the Mt. Fuji group that multiple AGID
support is necessary, I think we could specify so, because the opinion
to allow single AGID support is not absolute if I understand correctly.
With regard to your second comment on the bus encryption, I would like
to point that the current draft proposal does not contain anything about
the bus encryption because AACS has not yet decided in detail when and
how it would be introduced.
I apologize the late submission of the draft specifications.
Atsushi Ishihara, Toshiba
>Date: 2005/07/12 (Tue) 02:46:11
>From: Henry Gabryjelski <henrygab at windows.microsoft.com>
>To: mtfuji5 at avc-pioneer.com, T10 at t10.org
>Cc: David Walp <dwalp at windows.microsoft.com>
>Subject: RE: Updated Draft for AACS Command Set
>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
>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
>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.
>(*) Driver verifier (verifier.exe) in Windows has such a tool that any
>client may enable. Also, some bus trace tools also enable this
>functionality for read-only devices.
>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.
>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
>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