advanced access content system (aacs) · advanced access content system (aacs) certification...

Advanced Access Content System (AACS)

Certification Questionnaire

Intel Corporation

International Business Machines Corporation

Microsoft Corporation

Panasonic Corporation

Sony Corporation

Toshiba Corporation

The Walt Disney Company

Warner Bros.

Revision 0.85

April 8, 2013

Advanced Access Content System: Certification Questionnaire

Revision 0.85 Page ii


This page is intentionally left blank.

Revision 0.85 Page iii



Revision 0.85 Page iv


Preface

Notice

THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. IBM, Intel, Microsoft Corporation, Panasonic Corporation, Sony Corporation, Toshiba Corporation, The Walt Disney Company and Warner Bros. disclaim all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein.

This document is subject to change under applicable license provisions.

Copyright © 2013 by Intel Corporation, International Business Machines Corporation,., Microsoft Corporation, Panasonic Corporation, Sony Corporation, Toshiba Corporation, The Walt Disney Company, and Warner Bros. Third-party brands and names are the property of their respective owners.

Intellectual Property

Implementation of the AACS specification requires a license from AACS LA LLC.

Contact Information

Please address inquiries, feedback, and licensing requests to AACS LA LLC:

• Licensing inquiries and requests should be addressed to [email protected].

• Feedback on this specification should be addressed to [email protected].

• The URL for the AACS LA LLC web site is http://www.aacsla.com.

Revision 0.85 Page v

mailto:[email protected]://www.aacsla.com/mailto:[email protected]



Revision 0.85 Page vi


Table of Contents

1 INTRODUCTION................................................................................................1

1.1 Purpose and Scope.............................................................................................................1

1.2 Overview.............................................................................................................................. 1

1.3 Organization of this Document..........................................................................................2

1.4 References........................................................................................................................... 21.4.1 Normative References....................................................................................................2

1.5 Document History...............................................................................................................3

1.6 Terminology......................................................................................................................... 3

CHAPTER 2AACS ROBUSTNESS RULES STRUCTURE AND REVIEW DERIVATION.......6

2 INTRODUCTION................................................................................................6

2.1 Organization of the Licensed Product Robustness Rules...............................................6

2.2 Construction – Generally Licensed Product Robustness Rules, 7.2...............................................................................7

2.3 Construction – Defeating Functions..................................................................................8

2.4 Construction – Keep Secrets and Maintain Integrity........................................................92.4.1 Enhanced SecurityLicensed Product Robustness Rules, 7.4.1...........................................................................12

2.5 Data Paths..........................................................................................................................12

2.6 Methods of Making Functions Robust.............................................................................132.6.1 Distribution of Decryption and Decoding Functions......................................................132.6.2 Distribution of AACS Bus Decryption and AACS Basic Decryption Functions.............142.6.3 Audio Watermark Detector............................................................................................152.6.4 Software........................................................................................................................ 152.6.5 Hardware...................................................................................................................... 232.6.6 Hybrid........................................................................................................................... 34

2.7 Level of Protection – Core FunctionsLicensed Product Robustness Rules, 7.7.............................................................................34

Revision 0.85 Page vii


2.8 Level of Protection – User-Accessible Busses...............................................................40

2.9 Level of Protection – Unprotected Outputs....................................................................41

2.10 Level of Protection – Watermark Requirements...........................................................42

2.11 Level of Protection – Handling of Volume ID, Media ID, Binding Nonce & PMSN.....42

2.12 Level of Protection – Key Conversion Data (KCD).......................................................43

..........................................................................................................................44

CHAPTER 3AACS CERTIFICATION QUESTIONNAIRE........................................................45

3 INTRODUCTION..............................................................................................45

3.1 Construction Review ........................................................................................................46

3.2 Content Authentication Review.......................................................................................50

3.3 Content Decryption Review..............................................................................................62

3.4 Host-Drive Authentication Review...................................................................................81

3.5 Output Protection Review.................................................................................................95

3.6 Miscellaneous Items Review..........................................................................................101

3.7 Watermark Requirements Review .................................................................................107

CHAPTER 4AACS METHOD OF PROTECTION REPORTS................................................108

Method of Protection Confidential Adopter Reports.........................................................108 INTEGRITY OF THE AACS LA CONTENT CERTIFICATE PUBLIC KEY..........................110 INTEGRITY OF THE CONTENT REVOCATION LIST.......................................................112 INTEGRITY OF THE MCS PUBLIC KEY............................................................................114 INTEGRITY OF THE PVAS PUBLIC KEY..........................................................................116 SECRECY OF THE DEVICE KEYS...................................................................................118 ENHANCED SECURITY OF THE DEVICE KEYS..............................................................120 SECRECY OF THE MEDIA KEY........................................................................................122 SECRECY OF THE MEDIA KEY VARIANT.......................................................................124 INTEGRITY OF THE MEDIA KEY BLOCK (MKB)..............................................................126 INTEGRITY OF THE PRERECORDED MEDIA SERIAL NUMBER (PMSN)......................128 SECRECY OF THE SEQUENCE KEYS.............................................................................130 SECRECY OF THE TITLE KEY.........................................................................................132

Revision 0.85 Page viii


SECRECY OF THE DATA KEY..........................................................................................134 SECRECY OF THE BUS KEY............................................................................................136 SECRECY OF THE VOLUME UNIQUE KEY.....................................................................138 SECRECY OF THE AACS ALGORITHMS.........................................................................140 SECRECY OF THE PROCESSING KEY...........................................................................142 INTEGRITY OF THE AACS LA PUBLIC KEY....................................................................144 INTEGRITY OF THE DEVICE BINDING NONCE..............................................................146 SECRECY OF THE DRIVE PRIVATE KEY........................................................................148 SECRECY OF HOST PRIVATE KEY (Drive, Only)............................................................150 INTEGRITY OF THE DRIVE REVOCATION LIST.............................................................152 INTEGRITY OF THE PARTIAL MKB (INCLUDING THE HOST REVOCATION LIST) (Drive, Only) 154 SECRECY OF THE PSEUDORANDOM NUMBER GENERATOR CONSTANTS.............156

APPENDIX ARECOMMENDED USE AND CASE STUDIES (INFORMATIONAL)................158

A INTRODUCTION..........................................................................................158

A.1 Title Key Extraction by Memory Dump (Informational).............................................158

A.2 Licensed Drive Memory Modification (Informational)................................................159

Revision 0.85 Page ix


List of Tables

TABLE 2.2-1 - CONSTRUCTION, GENERALLY..................................................8

TABLE 2.3-2 - CONSTRUCTION, DEFEATING FUNCTIONS.............................9

TABLE 2.4-3 - CONSTRUCTION - KEEP SECRETS AND MAINTAIN INTEGRITY..............................................................................................................................10

TABLE 2.4-4 – MISUSE OF AACS KEY MATERIAL.........................................11

TABLE 2.4-5 – ENHANCED SECURITY.............................................................12

TABLE 2.5-6 – DATA PATHS.............................................................................13

TABLE 2.6-7 – PROTECTION METHOD REQUIREMENTS – DISTRIBUTED FUNCTIONS.........................................................................................................14

TABLE 2.6-8 BUS DECRYPTION AND BASIC DECRYPTION FUNCTIONS. .14

TABLE 2.6-9 AUDIO WATERMARK...................................................................15

TABLE 2.6-10 – PROTECTION METHOD REQUIREMENTS - SOFTWARE....16

TABLE 2.6-11 – PROTECTION METHOD REQUIREMENTS - HARDWARE...24

TABLE 2.6-12 – PROTECTION METHOD REQUIREMENTS – HARDWARE/SOFTWARE HYBRIDS..................................................................34

TABLE 2.7-13 – PROTECTION LEVEL REQUIREMENTS – CORE FUNCTIONS.36

TABLE 2.8-14 – PROTECTION LEVEL REQUIREMENTS – USER-ACCESSIBLE BUSSES...............................................................................................................41

TABLE 2.9-15 – PROTECTION LEVEL REQUIREMENTS - OUTPUTS...........41

Revision 0.85 Page x


TABLE 2.11-16 – PROTECTION LEVEL REQUIREMENTS – HOST-DRIVE....43

TABLE 2.12-17 – PROTECTION LEVEL REQUIREMENTS - KCD...................43

Revision 0.85 Page x


Chapter 1Introduction

1 Introduction

1.1 Purpose and Scope

The Advanced Access Content System (AACS) specifications define an advanced, robust and renewable method for protecting digital entertainment content. In addition to the robust cryptographic methods defined by AACS, the security of the overall content protection system depends critically on the robustness of the Adopter’s implementation. This Certification Questionnaire is provided as an aid to the correct implementation of the AACS Robustness Rules for hardware, software and hybrid implementations of the AACS specifications in a Licensed Product. AACS LA requires Adopters to complete and submit the Certification Questionnaire (Chapter 3) for each hardware model, software version, or hybrid version of a Licensed Product they ship, with exceptions for subsequent models that do not differ materially in methods of compliance, as described in the License Agreement.

Inasmuch as the Certification Questionnaire does not address all elements required for the manufacture of a Compliant product, Adopter is strongly advised to review carefully the complete AACS Specifications and License Agreement, including the Compliance Rules and Robustness Rules, so as to evaluate thoroughly its design, analysis and testing procedures, and the compliance of its Licensed Products. Adherence with all applicable requirements of the AACS Specifications and Adopter Agreement is what determines whether a Licensed Product is compliant, not merely a satisfactory completion of the AACS Certification Questionnaire.

1.2 Overview

The Certification Questionnaire contained in this document was created by framing certain requirements from the Robustness Rules as YES/NO questions, and then grouping those questions according to product component.

As an adjunct to the Certification Questionnaire, AACS LA requires the Adopter to complete Method of Protection Reports for the Secrecy and Integrity Required Values (see reference [1] , Robustness Rules, Appendix 1). Although Method of Protection Reports are not provided to AACS, the Adopter must confirm in the Review that these forms have been completed and filed in accordance with the AACS Adopter Agreement (reference [1]).

This document does not prescribe specific methods for making products robust. The Adopter must make those design decisions, whether by contracting third parties experienced in tamper resistant product design, or by building and utilizing such competency within their own company. The AACS

Initial/Date Revision 0.85 Page 1


Certification Questionnaire is one aid in the design process, and a wide variety of other resources are available outside of AACS. They include examples of publications and conferences on tamper-resistant software and hardware design, as well as examples of parties who may offer related training, consulting or engineering services. It is a common practice to get third party assistance when doing a security review of a content protection product, regardless of a company’s internal expertise, and AACS LA strongly encourages Adopters to take advantage of such firms, during design, development and test of their AACS Licensed Product. Notwithstanding whether any particular design or production work is reviewed, outsourced or handled by contractors, compliance with the requirements of the AACS Specification and License Agreement remains the responsibility of the Adopter.

1.3 Organization of this Document

This document consists of the following chapters:

Chapter 1 provides the AACS Certification Questionnaire introduction and overview, and references to related AACS documents.

Chapter 2 provides a guide to reading the Licensed Product Robustness Rules, and explains the relationship of those rules to the AACS Certification Questionnaire.

Chapter 3 contains the AACS Certification Questionnaire and Protection Method Reports forms.

Appendix A provides informational examples illustrating how to use the AACS Certification Questionnaire as a tool for improving implementation robustness.

1.4 References

1.4.1 Normative References

This AACS Certification Questionnaire shall be used in conjunction with the following AACS documents. When the documents are superseded by an approved revision, the revision shall apply.

[1] AACS LA, AACS Adopter Agreement, v0.92 or greater

[2] AACS LA, AACS Introduction and Common Cryptographic Elements book, v0.952 or greater

[3] AACS LA, AACS Pre-recorded Video Book, v0.952 or greater

[4] AACS LA, AACS Recordable Video Book, v0.952 or greater

[5] AACS LA, AACS Prepared Video Book, v0.952 or greater

[6] AACS Blu-ray Disc Prepared Video Book, v0.952 or greater



[7] AACS Blu-ray Disc Pre-recorded Book, v0.952 or greater

[8] AACS Blu-ray Disc Recordable Book, v0.952 or greater

[9] AACS HD DVD and DVD Prepared Video Book, v0.952 or greater

[10] AACS HD DVD and DVD Pre-recorded Book, v0.952 or greater

[11] AACS HD DVD and DVD Recordable Book, v0.952 or greater

[12] AACS Signed CSS Content Book, v0.952 or greater

1.5 Document History

This document version 0.85 is the first draft of the AACS Certification Questionnaire.

1.6 Terminology

The following terms are used in this document and defined in the AACS Adopter Agreement (reference [1]), the AACS Introduction and Common Cryptographic Elements book (reference [2]) or the AACS Pre-recorded Video Book (reference [3]).

Term/Acronym Reference

AACS Content Reference [1], Exhibit E, Part 1, Section 2.3

AACS LA Content Certificate Public Key

Reference [3], Section 2.6

AACS LA Public Key Reference [2], Section 4.3

Binding Nonce Reference [2], Section 1.8

Circumvention Devices Reference [1], Exhibit E, Part 2, Section 7.7.1

Constrained Image Reference [1], Exhibit E, Part 1, Section 2.17

Content Certificate Reference [3], Section 2.4

Content Hash Table (CHT) Reference [3], Section 2.3

Content Protection Requirements Reference [1], Exhibit E, Part 1, Section 2.18

Content Revocation List (CRL) Reference [3], Section 2.7

Device Keys Reference [2], Section 3.1

Drive Certificate Reference [2], Section 4.1




Drive Private Key Reference [2], Section 4.1

Drive Revocation List (DRL) Reference [2], Section 4.3.

Enhanced Security Reference [1], Exhibit E, Part 2, Section 7.4.1

Hardware implementation See Hardware, reference [1], Exhibit E, Part 2, Section 7.6.5

Host Certificate Reference [2], Section 4.2.

Host Private Key Reference [2], Section 4.2

Host Revocation List (HRL) Reference [2], Section 3.2.5.1.2.

Hybrid implementation See Hybrid, reference [1], Exhibit E, Part 2, Section 7.6.6

Integrity Required Values Reference [1], Exhibit E, Appendix 1

Key Conversion Data (KCD) Reference [2], Section 3.2.5.1.1

Licensed Product Reference [1], Exhibit E, Attachment 1, Section 1.21

Licensed Product Robustness Rules Reference [1], Exhibit E, Part 2, Section 7

Media Identifier or Media ID Reference [2], Section 1.8

Media Key Reference [2], Section 1.8

Media Key Block (MKB) Reference [2], Section 1.8

Prerecorded Media Serial Number (PMSN)


Proactive Renewal Reference [1], Exhibit E, Part 1, Section 2.43

professional tools Reference [1], Exhibit E, Part 2, Section 7.7.2

random/pseudorandom number generator values k and S


Secrecy Required Values Reference [1], Exhibit E, Appendix 1

Sequence Key Block (SKB) Reference [3], Chapter 4

Sequence Keys Reference [3], Section 4.2.1

Signed Code Reference [1], Exhibit E, Part 2, Section 7.6.4..2

Software implementation See Software, reference [1], Exhibit E, Part 2, Section 7.6.4




Specialized Tools Reference [1], Exhibit E, Part 2, Section 7.7.1

Specifications Reference [1], Section 1.76

Title Key Reference [2], Section 1.8

Usage Rules

User Accessible Bus (UAB) Reference [1], Exhibit E, Part 1, Section 2.54

Volume Identifier or Volume ID Reference [2], Section 1.8

Volume Unique Key Reference [3], Section 3.3

Widely Available Tools Reference [1], Exhibit E, Part 2, Section 7.7..1



Chapter 2AACS Robustness Rules Structure and

Review Derivation

2 Introduction

This section is intended to assist the product designer in understanding the structure and organization of the Licensed Product Robustness Rules, and how the items found in the AACS Certification Questionnaire were derived from those rules. Note that in various places references are made to the actual Licensed Product Robustness Rules. To get the precise wording of those rules, please read reference [1], Exhibit E, Part 2, Section 7 This document is not meant to interpret the Robustness Rules or any other provisions of the AACS License Agreement, and that agreement takes precedence over this document to the extent there are any conflicts.

2.1 Organization of the Licensed Product Robustness Rules

The AACS Licensed Product Robustness Rules are organized into four key areas. This results in four kinds of requirements and consequently four kinds of review questions. These are:

Construction General questions about the “construction,” or design, of the Licensed Product. This includes resisting modifications that defeat the Content Protection Requirements, not including means by which those requirements can be defeated, and maintaining secrecy and integrity of keys and other items.

Data paths Questions about where Decrypted AACS Content may be found and how it is protected between decryption and output.

Protection methods Questions about the methods used to meet data path and construction requirements in hardware and software.

Levels of Protection

Questions about how resistant protection methods are to attack, as expressed in terms of tools and level of effort used in the attack.

Each of these categories of questions are detailed, below. For each set of questions, the section of the relevant AACS Licensed Product Robustness Rules is given.

Chapter 3 contains the AACS Certification Questionnaire rearranged by design component category. The AACS Certification Questionnaire must be completed by Adopters and provided to AACS LA, in accordance with the AACS Adopter Agreement (reference [1]).



The majority of these questions apply to all implementations. Some are specific to the optical drive component of an AACS implementations. These questions are marked accordingly (Drive, only).

2.2 Construction – Generally Licensed Product Robustness Rules, 7.2

Section 7.2 of the Licensed Product Robustness Rules is about resisting modification of a Licensed Product (or its performance) to defeat the Content Protection Requirements. Understanding this section requires paying attention to such phrases as “clearly designed” and “effectively frustrate attempts”, and to the definition of Content Protection Requirements. It should also be noted that adversaries could attempt to modify a Licensed Product’s performance to defeat the Content Protection Requirements by altering or utilizing product functions that are not related to security or part of the Licensed Product itself.

The Content Protection Requirements are the applicable content protection requirements of AACS set forth in the Specifications and Compliance Rules, including but not limited to:

Content protection technologies Watermark Requirements Output protections Output restrictions Recording protections Recording limitations

Protections and limitations on copying (including but not limited to Managed Copy and Move)

Triggering of analog protection systems

Here, examples of “content protection technologies” would be technologies such as host-drive authentication, verification of Content Certificate signatures and verification of Drive Revocation List version.



Table 2.2-1 - Construction, Generally

# AACS Certification Questionnaire – Construction, Generally

1) Is the Licensed Product manufactured in a manner clearly designed to effectively frustrate attempts to modify it, or its performance, to defeat applicable Content Protection Requirements of AACS set forth in the Specifications and Compliance Rules, including but not limited to

• Content protection technologies (such as host-drive authentication, verification of Content Certificate signatures, and verification of Drive Revocation List version),

• Watermark Requirements• Output protections,• Output restrictions,• Recording protections,• Recording limitations, • Protections and limitations on copying (including but not limited to Managed Copy

and Move), and

• Triggering of analog protection systems,

consistent with related requirements in subsequent sections regarding protection methods (Compliance Rules, Section 7.6 and subsections) and levels of protection (Compliance Rules, Sections 7.7 through and including 7.12).

2.3 Construction – Defeating Functions

Licensed Product Robustness Rules, 7.3

Section 7.3 of the Licensed Product Robustness Rules addresses the design of the Licensed Product from the perspective of not including means by which the Content Protection Requirements and other requirements can be defeated.

Recalling the definition of Content Protection Requirements, we derive these additional Defeating Functions review items.



Table 2.3-2 - Construction, Defeating Functions

# AACS Certification Questionniare – Construction, Defeating Functions

1) Does the design include

• Switches, buttons, jumpers or software equivalents thereof,• Specific traces (electrical connections) that can be cut, or• Functions (including service menus and remote-control functions),

in each case by which applicable Content Protection Requirements of AACS set forth in the Specifications and Compliance Rules, including but not limited to

• Content protection technologies (such as host-drive authentication, verification of Content Certificate signatures, and verification of Drive Revocation List version),

• Watermark Requirements,• Output protections,• Output restrictions,• Recording protections,• Recording limitations, • Protections and limitations on copying (including but not limited to Managed

Copy and Move), and

• Triggering of analog protection systems

can be defeated, or by which compressed Decrypted AACS Content can be exposed to output, interception, retransmission or copying?

2.4 Construction – Keep Secrets and Maintain Integrity

Licensed Product Robustness Rules, 7.4AACS Compliance Rules, Appendix 1

Section 7.4 of the Licensed Product Robustness Rules deals with the design of the Licensed Product from the perspective of maintaining the secrecy and integrity of key AACS objects. As elsewhere, understanding this section requires paying attention to such phrases as “clearly designed” and “effectively frustrate attempts.” It also requires understanding the identification of Secrecy Required and Integrity Required items in Appendix 1. Note that Secrecy Required items include intermediate data items derived from other Secrecy Required Values, such as Volume Unique Keys and Processing Keys, and the random pseudorandom number generator constants k and S, as defined in the Specifications.

Note that in addition to robustness requirements for keeping secrets, Licensed Products are subject to key expiration if they are used for exposure of AACS Keys. See the AACS License Agreement for details regarding expiration criteria.



Table 2.4-3 - Construction - Keep Secrets and Maintain Integrity

# AACS Certification Questionnaire – Construction - Keep Secrets and Maintain Integrity

1) Is the Licensed Product manufactured in a manner that is clearly designed to effectively frustrate attempts to discover or reveal

• Device Keys, Sequence Keys, Drive Private Key, Host Private Key, Media Keys, Title Keys, Cmfg, Data Keys, Bus Keys, or the Media Key Variant

• Intermediate data items derived from such values, such as Volume Unique Keys, Processing Keys, the Volume ID, or the random/pseudorandom number generator constants k and S as defined in the Specifications, or

• Algorithms described in specifications marked Confidential, including “HD DVD and DVD Pre-recorded Book Confidential Part for CE System” and “HD DVD and DVD Pre-recorded Book Confidential Part for PC-based System,”

consistent with related requirements in subsequent sections regarding protection methods and levels of protection?

2) Is the Licensed Product manufactured in a manner clearly designed to effectively frustrate attempts to cause such product to use

• AACS LA Public Key,• AACS LA Content Certificate Public Key,• MCS Public Key,• PVAS Public Key,• Device Binding Nonce• Pre-recorded Media Serial Number,• Drive Revocation List, or individual components thereof, when being stored in non-

volatile storage by a Licensed Product as required in the Specifications,

• Content Revocation List, or individual components thereof when being stored in non-volatile storage by a Licensed Product as required in the Specifications,

• Media Key Block, when being stored in non-volatile storage by a Licensed Product as required in the Specifications, or

• Partial MKB, or individual components thereof when being stored in non-volatile storage by a Licensed Product as required in the Specifications,

after unauthorized modification of such values occurs?

Section 7.4 also requires that Licensed Products not use Secrecy Required or Integrity Required values for purposes other than those defined by AACS in the Specifications and Approved Licenses. These specific requirements are part of the AACS Certification Questionnaire.



Table 2.4-4 – Misuse of AACS Key Material

# AACS Certification Questionnaire – Misuse of Key Material Requirements

1) Does the Licensed Product use Device Keys, Processing Keys or Sequence Keys for purposes other than those defined by AACS in the Specifications and Approved Licenses?

2) Does the Licensed Product use the Host Private Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

3) (Drive, only) Does the Licensed Product use the Drive Private Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

4) Does the Licensed Product use the Volume Unique Key, Media Key or Title Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

5) Does the Licensed Product use the Cmfg for purposes other than those defined by AACS in the Specifications and Approved Licenses?

6) Does the Licensed Product use the Data Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

7) Does the Licensed Product use the Bus Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

8) Does the Licensed Product use the Media Key Variant for purposes other than those defined by AACS in the Specifications and Approved Licenses?

9) Does the Licensed Product use the Volume ID for purposes other than those defined by AACS in the Specifications and Approved Licenses?

10) Does the Licensed Product use the Algorithms described in specifications marked Confidential, including “HD DVD and DVD Pre-recorded Book Confidential Part for CE System” and “HD DVD and DVD Pre-recorded Book Confidential Part for PC-based System,” for purposes other than those defined by AACS in the Specifications and Approved Licenses?

11) Does the Licensed Product use the Random/Pseudorandom Number Generator constants k and S for purposes other than those defined by AACS in the Specifications and Approved Licenses?

12) Does the Licensed Product use the AACS LA Public Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

13) Does the Licensed Product use the AACS LA Content Certificate Public Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

14) Does the Licensed Product use the Managed Copy Server Public Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

15) Does the Licensed Product use the PVAS Public Key for purposes other than those defined by AACS in the Specifications and Approved Licenses?

16) Does the Licensed Product use the Device Binding Nonce for purposes other than those defined by AACS in the Specifications and Approved Licenses?



# AACS Certification Questionnaire – Misuse of Key Material Requirements

17) Does the Licensed Product use the Pre-recorded Media Serial Number (PMSN) for purposes other than those defined by AACS in the Specifications and Approved Licenses?

18) Does the Licensed Product use the Drive Revocation List (DRL) for purposes other than those defined by AACS in the Specifications and Approved Licenses?

19) Does the Licensed Product use the Content Revocation List (CRL) for purposes other than those defined by AACS in the Specifications and Approved Licenses?

20) Does the Licensed Product use the Media Key Block (MKB) for purposes other than those defined by AACS in the Specifications and Approved Licenses?

21) (Drive, only) Does the Licensed Product use the Partial MKB (including the Host Revocation List) for purposes other than those defined by AACS in the Specifications and Approved Licenses?

2.4.1 Enhanced SecurityLicensed Product Robustness Rules, 7.4.1

There are additional requirements with regards to Device Keys, under the heading of Enhanced Security. The adopter must comply with either 7.4.1 (a) or 7.4.1 (b).

Table 2.4-5 – Enhanced Security

# AACS Certification Questionnaire – Enhanced Security

1) Does the implementation comply with AACS Licensed Product Robustness Rules Section 7.4.1 (a)?

2) Does the implementation comply with AACS Licensed Product Robustness Rules Section 7.4.1 (b)?

2.5 Data Paths


Data path robustness requirements address where Decrypted AACS Content may be found, and how it is protected between decryption and output.

Licensed Product Robustness Rules, 7.5.1 Video Portion

This section deals with the protection of uncompressed, decrypted AACS Content while it is traversing a User-Accessible Bus. Understanding this section requires paying attention to such



phrases as “clearly designed,” and to the definitions of User-Accessible Bus and Constrained Image. Also, note that there are related requirements in subsequent sections regarding levels of protection.

Table 2.5-6 – Data Paths

# AACS Certification Questionnaire – Data Path Requirements

1) Within the Licensed Product, is the video portion of Decrypted AACS Content not present on any User-Accessible Bus in an analog form, conformant with the related conditions in Licensed Product Robustness Rules, 7.5.2?

2) Within the Licensed Product, is the video portion of Decrypted AACS Content not present on any User-Accessible Bus in unencrypted, compressed form, conformant with the related requirement regarding level of protection in Licensed Product Robustness Rules 7.7 (Level of Protection – Core Functions) ?

3) Is the Licensed Product clearly designed such that when the video portion of uncompressed Decrypted AACS Content is transmitted over a User-Accessible Bus in digital form, it is either: (x) limited to Constrained Imageor (y) made reasonably secure from unauthorized interception,in either case conformant with the related requirement regarding level of protection in Licensed Product Robustness Rules 7.8 (Level of Protection – User-Accessible Busses)?

Licensed Product Robustness Rules, 7.5.2 (analog User Accessible Bus and test points)

Section 7.5.2 provides additional clarification regarding analog User-Accessible Busses, specifically, the inclusion of means such as analog test points which do not “readily facilitate end user access”, and cases where that is presumed.

2.6 Methods of Making Functions Robust


This section (including its sub-sections) addresses methods used in hardware, software and hybrid Licensed Product implementations to meet data path and construction requirements set forth in previous sections.

2.6.1 Distribution of Decryption and Decoding Functions

Licensed Product Robustness Rules, 7.6.1

This section pertains to the video portion of Decrypted AACS Content flowing between portions of a Licensed Product that perform decryption and portions that perform decode. Note that this is



independent of whether such flow includes a User-Accessible Bus, which was focus of data path requirements in previous sections. Understanding this section requires paying attention to such phrases as “associated and otherwise integrated with each other,” “in any usable form” and “reasonably secure.”

Table 2.6-7 – Protection Method Requirements – Distributed Functions

# AACS Certification Questionnaire – Protection Method Requirements – Distributed

In the Licensed Product, where the video portion of Decrypted AACS Content is delivered from one part of the product to another, are the portions of the Licensed Product that perform authentication and decryption and the compressed video (e.g. MPEG or similar) decoder designed and manufactured in a manner associated and otherwise integrated with each other such that the video portion of Decrypted AACS Content in any usable form flowing between them is reasonably secure from being intercepted or copied except as authorized by the Compliance Rules?

2.6.2 Distribution of AACS Bus Decryption and AACS Basic Decryption Functions


This section pertains to the video portion of Bus-decrypted AACS Content flowing between portions of a Licensed Product that perform Bus Decryption and portions that perform AACS Basic Decryption. Note that this is independent of whether such flow includes a User-Accessible Bus, which was focus of data path requirements in previous sections. Understanding this section requires paying attention to such phrases as “associated and otherwise integrated with each other,” “in any usable form” and “reasonably secure.”

Table 2.6-8 Bus Decryption and Basic Decryption Functions

# AACS Certification Questionnaire – Protection Method Requirements – Distributed

In the Licensed Product, where the video portion of Bus-decrypted AACS Content is delivered from one part of the Licensed Product to another, are the portions of the Licensed Product that perform AACS Bus Decryption and those that perform AACS Basic Decryption designed and manufactured in a manner associated and otherwise integrated with each other such that the video portion of Bus-decrypted AACS Content in any usable form flowing between them is reasonably secure from being intercepted or copied except as authorized by the Compliance Rules?



2.6.3 Audio Watermark Detector


This section pertains to the Audio Watermark Detector and content flowing between the Audio Watermark Detector and the Licensed Access Product. Note that this is independent of whether such flow includes a User-Accessible Bus, which was focus of data path requirements in previous sections. Understanding this section requires paying attention to such phrases as “associated and otherwise integrated with each other.”

Table 2.6-9 Audio Watermark

# AACS Certification Questionnaire – Protection Method Requirements – Watermark

Are the Licensed Access Product and the Audio Watermark Detector it uses designed and manufactured in a manner associated and otherwise integrated with each other such that unauthorized modification or blockage of the audio data, notices, or other information conveyed between them is expected to result in a failure of the Licensed Access Product to provide the requested playback or copying operation?

2.6.4 Software


This section (including its sub-sections) addresses methods used in Software implementations to meet construction requirements set forth in previous sections. A definition of “Software” is given, which in turn refers to the definition of “Hardware” provided in a later section.

Licensed Product Robustness Rules, 7.6.4.1

This sub-section deals with methods used by Software implementations to comply with the construction requirements in Licensed Product Robustness Rules 7.4 regarding keeping secrets and maintaining integrity, and use of obfuscation techniques to disguise the methods used. Characteristics and examples of methods are given, though the examples themselves are not requirements. For this reason, as part of the review questions below, AACS requires the Adopter to document the precise methods being used to afford those protections, and affirm to AACS through the review that this document exits. The document must be provided to an Authorized Certification Entity for their review before issuance of an Acknowledgement of Compliance Testing is issued. In the tables in Section 3, the Adopter must check all boxes which are appropriate. When ‘Other’ is appropriate, the Adopter is not required to specify in the review what that method or methods are, but they must be included in the AACS Protection Methods document the Adopter is required to maintain.



Table 2.6-10 – Protection Method Requirements - Software

# AACS Certification Questionnaire – Protection Method Requirements – Software

1) In the Licensed Product, are reasonable methods used to maintain the secrecy of the Device Keys or other values identified as secrecy required in Appendix 1 of the Compliance Rules, including but not limited to encryption, execution of a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation clearly designed to effectively disguise and hamper attempts to discover the approaches used?

2) For a Licensed Product implementing the additional requirement in Licensed Product Robustness Rules 7.4.1(b) regarding secrecy of Device Keys:

Are reasonable methods used that effectively and uniquely associate those values with a single device, such as by encrypting the values using a key that is unique to a single device, or some other reasonable method?

Are reasonable methods used that effectively isolate those values from exposure by mere use of programming instructions or data, such as by using the values only inside a secure processor or some other reasonable method?

For the above, are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of Device Keys?

3) Are reasonable methods used to maintain the secrecy of Sequence Keys, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of Sequence Keys?

4) Are reasonable methods used to maintain the secrecy of the Host Private Key, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Host Private Key?

5) (Drive, only) Are reasonable methods used to maintain the secrecy of the Drive Private Key such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Drive Private Key?




6) Are reasonable methods used to maintain the secrecy of Media Keys, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Media Keys?

7) Are reasonable methods used to maintain the secrecy of Title Keys, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Title Keys?

8) Are reasonable methods used to maintain the secrecy of the Cmfg, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Cmfg?

9) Are reasonable methods used to maintain the secrecy of the Data Key, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Data Key?

10) Are reasonable methods used to maintain the secrecy of the Bus Key, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Bus Key?

11) Are reasonable methods used to maintain the secrecy of the Media Key Variant, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Media Key Variant?

12) (HD DVD only) Are reasonable methods are used to maintain the secrecy of algorithms described in AACS specifications marked Confidential, including “HD DVD and DVD Pre-recorded Book Confidential Part for CE System” and “HD DVD and DVD Pre-recorded Book Confidential Part for PC-based System”, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of these algorithms?




13) Are reasonable methods used to maintain the secrecy of Processing Keys such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Processing Keys?

14) Are reasonable methods are used to maintain the secrecy of Volume Unique Keys, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Volume Unique Keys?

15) Are reasonable methods are used to maintain the secrecy of Volume ID, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the Volume ID?

16) Are reasonable methods used to maintain the secrecy of the Random/Pseudorandom Number Generator constants k and S, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the secrecy of the PRNG constants?

17) Are reasonable methods used to maintain the integrity of the AACS LA Public Key such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the AACS LA Public Key?

18) Are reasonable methods used to maintain the integrity of the AACS LA Content Certificate Public Key, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the AACS LA Content Certificate Public Key?

19) Are reasonable methods used to maintain the integrity of the MCS Public Key, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the MCS Public Key?




20) Are reasonable methods used to maintain the integrity of the PVAS Public Key, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the PVAS Public Key?

21) Are reasonable methods used to maintain the integrity of the Device Binding Nonce, such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the Device Binding Nonce?

22) Are reasonable methods used to maintain the integrity of the Pre-recorded Media Serial Number (PMSN), such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the PMSN?

23) Are reasonable methods used to maintain the integrity of the Drive Revocation List (DRL), such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the DRL?

24) Are reasonable methods used to maintain the integrity of the Content Revocation List (CRL), such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the CRL?

25) Are reasonable methods used to maintain the integrity of the Media Key Block (MKB), such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the MKB?

26) (Drive, only) Are reasonable methods used to maintain the integrity of the Partial MKB (including the Host Revocation List), such as encryption, executing a portion of the implementation in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

Are techniques of obfuscation used to effectively disguise and hamper attempts to discover the approaches used to maintain the integrity of the MKB (including the Host Revocation List)?




This sub-section deals with integrity checking methods for Software implementations, and the consequence of unauthorized modification in such implementations relevant to construction and data path requirements set forth in previous sections. The types of potential modifications to be addressed, and the expected consequence of such modifications, are described. Characteristics and examples of minimum required methods are also given.

Note the conceptual relationship between this section and the requirements of Licensed Product Robustness Rules 7.2 (Construction – Generally) regarding resistance to modifications that defeat the Content Protection Requirements.


27) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify signature verification of the Drive Revocation List will be expected to result in the failure of the authorized authentication and/or decryption function?

28) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify signature verification of the Host Certificate or the Drive Certificate will be expected to result in the failure of the authorized authentication and/or decryption function?

29) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify signature verification of the Content Certificate will be expected to result in the failure of the authorized authentication and/or decryption function?

30) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify verification of the content against the Content Hash Table or verification of the hash of the Usage Rules will be expected to result in the failure of the authorized authentication and/or decryption function?

31) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify message authentication when reading the Volume ID, PMSN, Media ID or Binding Nonce from the AACS Drive will be expected to result in the failure of the authorized authentication and/or decryption function?

32) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to integrity obligations with respect to the AACS LA Public Key will be expected to result in the failure of the authorized authentication and/or decryption function?




33) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to integrity obligations with respect to the AACS LA Content Certificate Public Key will be expected to result in the failure of the authorized authentication and/or decryption function?

34) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to integrity obligations with respect to the MCS Public Key or the PVAS Public Key will be expected to result in the failure of the authorized authentication and/or decryption function?

35) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to integrity obligations with respect to the Content Revocation List (CRL) will be expected to result in the failure of the authorized authentication and/or decryption function?

36) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to integrity obligations with respect to the Media Key Block (MKB) will be expected to result in the failure of the authorized authentication and/or decryption function?

37) (Drive, only) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to integrity obligations with respect to the Partial MKB (including the Host Revocation List) will be expected to result in the failure of the authorized authentication and/or decryption function?

38) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to Device Keys, Processing Keys and Sequence Keys will be expected to result in the failure of the authorized authentication and/or decryption function?

39) (Drive, only) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to the Drive Private Key will be expected to result in the failure of the authorized authentication and/or decryption function?

40) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to the Host Private Key will be expected to result in the failure of the authorized authentication and/or decryption function?

41) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to Media Keys, Title Keys and Volume Unique Keys will be expected to result in the failure of the authorized authentication and/or decryption function?




42) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to Bus Keys will be expected to result in the failure of the authorized authentication and/or decryption function?

43) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to the Cmfg will be expected to result in the failure of the authorized authentication and/or decryption function?

44) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to the Data Key will be expected to result in the failure of the authorized authentication and/or decryption function?

45) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to the Media Key Variant will be expected to result in the failure of the authorized authentication and/or decryption function?

46) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to the Pseudorandom Number Generator constants k and S will be expected to result in the failure of the authorized authentication and/or decryption function?

47) (HD DVD only) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to secrecy obligations with respect to algorithms described in AACS specifications marked Confidential, including “HD DVD and DVD Pre-recorded Book Confidential Part for CE System” and “HD DVD and DVD Pre-recorded Book Confidential Part for PC-based System?” will be expected to result in the failure of the authorized authentication and/or decryption function?

48) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to watermark detection and response obligations will be expected to result in the failure of the authorized authentication and/or decryption function function?

49) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify the enforcement of digital output restrictions will be expected to result in the failure of the authorized authentication and/or decryption function?

50) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to User-Accessible Bus restrictions and obligations will be expected to result in the failure of the authorized authentication and/or decryption function?




51) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify adherence to the requirement that content flowing between distributed decryption and decode functions be reasonably secure from interception will be expected to result in failure of the authorized authentication and/or decryption function?

52) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify the enforcement of recording limitations will be expected to result in the failure of the authorized authentication and/or decryption function?

53) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify the enforcement of content protection technologies will be expected to result in the failure of the authorized authentication and/or decryption function?

54) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify the enforcement of protections and limitations on copying (including Managed Copy and Move) will be expected to result in the failure of the authorized authentication and/or decryption function?

55) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify the enforcement of analog protection systems will be expected to result in the failure of the authorized authentication and/or decryption function?

56) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify recording protections will be expected to result in the failure of the authorized authentication and/or decryption function?

57) Does the implementation use Signed Code or a robust means of runtime integrity checking operating throughout the code to assure that attempts to modify output protections will be expected to result in the failure of the authorized authentication and/or decryption function?

2.6.5 Hardware


This section (including its sub-sections) addresses methods used in Hardware implementations to meet construction requirements set forth in previous sections. “Hardware” is defined as a physical device or component that implements Content Protection Requirements, in which any instructions or data (e.g., firmware) are either permanently embedded or are specific to the implementation and not accessible to the end user.




This sub-section deals with methods used by Hardware implementations to comply with the construction requirements in Licensed Product Robustness Rules 7.4 regarding keeping secrets and maintaining integrity. Characteristics and examples of methods are given, though the examples themselves are not requirements. For this reason, as part of the review questions below, AACS requires the Adopter to document the precise methods being used to afford those protections, and affirm to AACS through the review that this document exits. The document must be provided to an Authorized Certification Entity for their review before issuance of an Acknowledgement of Compliance Testing is issued. In the tables in Section 3, the Adopter must check all boxes which are appropriate. When ‘Other’ is appropriate, the Adopter is not required to specify in the review what that method or methods are, but they must be included in the AACS Protection Methods document the Adopter is required to maintain.

Table 2.6-11 – Protection Method Requirements - Hardware

# AACS Certification Questionnaire – Protection Method Requirements - Hardware

1) Are reasonable methods used to maintain the secrecy of the Device Keys, such as embedding Device Keys in silicon circuitry or firmware that cannot reasonably be read, encryption, executing a portion of the component in ring zero or supervisor mode, and/or embodiment in a secure physical implementation?

2) For a Licensed Product implementing the additional requirement in Licensed Product Robustness Rules 7.4.1(b) regarding enhanced security and secrecy of Device Keys:

Are reasonable methods used that effectively and uniquely associate those values with a single device, such as by encrypting the values using a key that is unique to a single device?

Are reasonable methods used that effectively isolate those values from exposure by mere use of programming instructions or data, such as by using the values only inside a secure processor?

3) Are reasonable methods used to maintain the secrecy of Sequence Keys, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

4) Are reasonable methods used to maintain the secrecy of the Host Private Key, such as encryption , executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?




5) (Drive, only) Are reasonable methods used to maintain the secrecy of the Drive Private Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

6) Are reasonable methods used to maintain the secrecy of Media Keys, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

7) Are reasonable methods used to maintain the secrecy of Title Keys, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data,?

8) Are reasonable methods used to maintain the secrecy of the Cmfg, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data,?

9) Are reasonable methods used to maintain the secrecy of the Data Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

10) Are reasonable methods used to maintain the secrecy of the Bus Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

11) Are reasonable methods used to maintain the secrecy of the Media Key Variant, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

12) (HD DVD only)Are reasonable methods used to maintain the secrecy of algorithms described in AACS specifications marked Confidential, including “HD DVD and DVD Pre-recorded Book Confidential Part for CE System” and “HD DVD and DVD Pre-recorded Book Confidential Part for PC-based System”, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

13) Are reasonable methods used to maintain the secrecy of Processing Keys, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?




14) Are reasonable methods used to maintain the secrecy of Volume Unique Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

15) Are reasonable methods used to maintain the secrecy of Volume ID, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

16) Are reasonable methods used to maintain the secrecy of the Pseudorandom Number Generator constants k and S, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

17) Are reasonable methods used to maintain the integrity of the AACS LA Public Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

18) Are reasonable methods used to maintain the integrity of the AACS LA Content Certificate Public Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

19) Are reasonable methods used to maintain the integrity of the MCS Public Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

20) Are reasonable methods used to maintain the integrity of the PVAS Public Key, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

21) Are reasonable methods used to maintain the integrity of the Device Binding Nonce, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

22) Are reasonable methods used to maintain the integrity of the PMSN, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?




23) Are reasonable methods used to maintain the integrity of the Drive Revocation List, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

24) Are reasonable methods used to maintain the integrity of the Content Revocation List, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?

25) Are reasonable methods used to maintain the integrity of the Media Key Block, such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation or isolating those values from exposure by mere use of programming instructions or data?

26) (Drive, only) Are reasonable methods used to maintain the integrity of the Partial MKB (including the Host Revocation List), such as encryption, executing a portion of the component in ring zero or supervisor mode, embodiment in a secure physical implementation, or isolating those values from exposure by mere use of programming instructions or data?


This sub-section deals with the consequence of attempts to modify Hardware implementations in a way that would compromise Content Protection Requirements. The types of attempted modifications to be addressed, and the expected consequence of such modifications, are described. Characteristics and examples of minimum required methods are also given.

Note the conceptual relationship between this section and the requirements of Licensed Product Robustness Rules 7.2 (Construction – Generally) regarding resistance to modifications that defeat the Content Protection Requirements.


27) Does the implementation use means such as

- a component that is soldered rather than socketed, or affixed with epoxy, or

- checking a signature on updateable firmware within a secure boot loader

to assure that attempts to modify signature verification of the Drive Revocation List would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?







to assure that attempts to modify signature verification of the Host Certificate or the Drive Certificate would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify signature verification of the Content Certificate would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify verification of the content against the Content Hash Table or verification of the hash of the Usage Rules would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify message authentication when reading the Volume ID, Media ID or Binding Nonce would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify adherence to integrity obligations with respect to the AACS LA Public Key would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?







to assure that attempts to modify adherence to integrity obligations with respect to the AACS LA Content Certificate Public Key would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify adherence to integrity obligations with respect to the Pre-recorded Media Serial Number (PMSN) would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify adherence to integrity obligations with respect to the MCS Public Key or PVAS Public Key would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify adherence to integrity obligations with respect to the Content Revocation List (CRL) would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify adherence to integrity obligations with respect to the Media Key Block (MKB) would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




38) (Drive, only) Does the implementation use means such as



to assure that attempts to modify adherence to integrity obligations with respect to the Partial MKB (including the Host Revocation List) would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify adherence to secrecy obligations with respect to Device Keys, Processing Keys and Sequence Keys would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?

40) (Drive, only) Does the implementation use means such as



to assure that attempts to modify adherence to secrecy obligations with respect to the Drive Private Key would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playback or copy AACS Content?




to assure that attempts to modify adherence to secrecy obligations with respect to the Host Private Key would pose a serious risk of rendering the Licensed Product unable to receive, decrypt, decode, playbac

advanced access content system (aacs) · advanced access content system (aacs) certification...

Documents