AACS 2.0 -1st draft - wikileaks.org 2.0 Architecture... · 4/7/15AACS CONFIDENTIAL2 •Overview &...

AACS 2.0 -1st draft

4/7/151AACS CONFIDENTIAL

4/7/15AACS CONFIDENTIAL2

• Overview & Status (BG & tech group support)

• BDA defined study areas (tech)

• AACS 2.0 Copy protection – high level architecture

• File rules and mechanics (DBEF)

• Process to approve list of output DRMs (BG)

• Copy protection for Bound Copy

• Additional areas investigated by AACS (Tech)

• Identified potential solutions to various aspects of the MovieLabs Specification for Content Protection Systems

• AACS initiatives

• Implementation Considerations (tech/BG)

• Licensing and business considerations (BG)

• Next Steps

Agenda


UHD Ecosystem DiagramTitle Key Server

UHDPlayer

Security ModuleServer

Time based release of Title Keys

Title based modifications to the security module

HDCP 2.2 connection

SFF

C-ENC

SFF

C-ENC

SFF

C-ENC

DBEF Bound Copy

AACS Key Server

DO NOT SHOW THISUPDATE BLOCK DIAGRAM


UHD PlayerTitle Key Server

UHDPlayer




HDCP 2.2 connection

SFF

C-ENC

SFF

C-ENC

SFF

C-ENC

DBEF Bound Copy

AACS Key Server


• Three sets of capabilities resident in all UHD Players

• AACS 1.x – for legacy discs

• AACS 2.0 – multiple choices

• AACS 2.0 (basic) – for discs where the Title Key is delivered with the disc and an online connection is not required

• AACS 2.0 (enhanced) – for discs where the Title Key is provided by an online connection

• Title diversity may also supported

UHD Player (with AACS 2.0)


• HW Rot

• Keys

• Certificates

• List more

• AACS

• Device key

• MKB

• Revocation lists

• AACS private and public keys

• List more

UHD Player Security Assets

X


• AES Symmetric Block Cipher Algorithm

• ECB Mode (AES-128E and AES-128D)

• CBC Mode (AES-128CBCE and AES-128CBCD)

• Counter Mode (AES-128)

• AES-based One-way Function (AES-G)

• Triple AES Generator (AES-G3)

• SHA-256 based AES Hashing Function (AES-H)

• SHA-256 Hashing Function

• Message Authentication Code (CMAC) [AES based]

• Digital Signature

• AACS_Sign and AACS_Verify based on ECDSA 256-bit and SHA-256

• Note: UHD Players must continue to support the crypto-algorithms used to playback legacy discs

AACS 2.0 Crypto-algorithms


Random Number Generator

• ML Statement: The platform shall support a true random number generator

• AACS Recommendation

• CE and PC devices do not have a way generate a true random number

• AACS Recommends that a deterministic RNG is also permitted as a random number source

• The initial seed (“Source Entropy Input” or SEI) can be injected at manufacturing time

• Platforms must securely save the state of DRNG after each use

• Recommendation is to permit RNGs that follow NIST 800-90 as is the case for HDCP2

Outputs and Link Protection• AACS will require use of HDCP 2.2 for output of 4K content

• Additionally, AACS will address transition from HDCP 1.4 to HDCP 2.2.

• Most existing TVs (2K/4K) have HDCP 1.4, for which down-converted output (2K resolution) should be allowed.

• AACS will define ‘HDCP 2.2 flag’. HDCP 2.2 is mandatory in players’ 4K output of such content in which HDCP 2.2 flag is on.

• TABLE D1 will be revised to reflect the above concept.

• AACS will provide a field that permits the selection of the output technology??

4/7/15AACS CONFIDENTIAL

9

Current TABLE D1

DTCP

DVI

HDCP

WMDRM/PlayReady

New TABLE D1 for 2K

DTCP

HDCP

WMDRM/PlayReady

New TABLE D1 for 4K

HDCP 2.2 and later

new entries upon AACS review/approval

Insert sato-san’slide


• Need to consult with MovieLabs if this requirement applies to UHD players that play content from optical discs

• If this is a requirement, need to develop an approach

License Key Binding

DO NOT SHOW THISUPDATE BLOCK DIAGRAM

Device Key Spaces for AACS1 and AACS2.0

• Device Key Spaces for HD and UHD players SHALL be separated

• Because AACS1 Device is prohibited to decrypt AACS2.0 content

• AACS2.0 Device needs to keep two Device Key Sets and two Host Certificates (Host Private Key) when it decrypt AACS1 content

• Revocation List Record (Host/Drive) in MKB is also different from AACS1

• Otherwise, Host/Drive ID must not overlap between AACS1 and AACS2.0

• [Q] Which MKB Type is assigned to AACS2.0?

• In AACS1.1, Type 4 is used because of avoiding legacy issues

• However, in AACS2.0, there is no legacy issues.

• Then, two kinds of NEW types should be prepared

AACS CONFIDENTIAL

TOSHIBA T

O REVIS

E

4/7/1511

Pairing of Host Private Key and Device Key Set

• Synchronized revocation of both Host Private Key /Certificate and Device Key Set SHOULD be considered.

• AACS1 doesn’t provide the synchronized revocation

• For above purpose, some information for identifying Device Key Set is necessary to be put in Host Certificate.

• device number “d” can be used

• Adopter needs to implement specified pair of Host Certificate (Host Private Key) and Device Key Set in the Device.

• KGFs for Host Certificate (Host Private Key) and Device Key Set need to align for generation.

• License Agreement needs to have NEW provision

• A new Revocation Criterion

• If either of Host Private Key or Device Key(s) is revealed, both paired Keys would be revoked.

AACS CONFIDENTIAL

TOSHIBA T

O REVIS

E

4/7/1512

Host Certificate

Certificate Type

Reserved || DKS || BEC

Length

Host ID (6-byte)

Reserved

Host Public Key (40-byte)

Signature Data (40-byte)

Certificate Type

Reserved || DKS || BEC

Length

Host ID (6-byte)

Reserved

Host Public Key (64-byte)

Signature Data (64-byte)

device number “d” of paired Device Key Set (4-byte)

AACS1

AACS2.0 (proposal)

Device number “d”(31-bit)

Host Type (1-bit) 0: Type A Device Key (Enhanced Robustness) 1: Type C Device Key (Proactive Renewal)

Host ID is different between AACS1 and AACS2.0even if the Host can decrypt both AACS1 and AACS2.0 content

AACS CONFIDENTIAL

TOSHIBA T

O REVIS

E

4/7/1513


• Trusted Execution Environment

• Secure media pipeline that provides end-to-end protection that encompasses, at a minimum, decryption through to protected output

• Secure processing environment isolated by hardware mechanisms running only authenticated code for performing critical operations.

• The security of this environment must be proven with extensive testing. E.g., secure OS, media pipeline configuration, handling sensitive cryptography

• The platform shall be able to protect memory of the secure execution environment against access from untrusted code & devices

• The platform shall support runtime integrity checking of secure applications

Robustness Rules Enhancements for UHD Players


• The platform shall support a secure chain of trust for code that executes in the secure execution environment

• The root of trust shall be securely provisioned, e.g., permanently factory burned

• HW ROT - The platform shall support a device-unique private key for protecting stored secrets. It shall be:

• securely provisioned, e.g., permanently factory burned using encrypted communication in the facility so that keys are not revealed in network or other operational logs,

• usable in certain crypto ops, but never visible even to trusted software,

• usable (as a means to securely provision keys) to identify and authenticate the device, and usable (as a means to securely provision keys) to bind content to host and/or storage

Robustness Rules Enhancements for UHD Players – Root of Trust


Playback from UHD DiscTitle Key Server

UHDPlayer




HDCP 2.2 connection

SFF

C-ENC

SFF

C-ENC

SFF

C-ENC

DBEF Bound Copy

AACS Key Server


• Use Cases

• Disc does not require online connection – Title Keys and Security Module (if provided) delivered on disc

• Disc requires online connection for first playback, but first playback has occurred and Title Keys have been downloaded and cached

• List the assets provided on the disc

• MKB and records

• Security module (optional)

• Process –

• Determine what kind of disc (1.x or 2.0)

• Is online connection required (not required, or Title Key already downloaded and cached)

• Process MKB and derive Title Key

• Is there a Security Module on the disc (if yes, load Security Module)

Playback from Disc


Playback using On-line Connection Title Key Server

UHDPlayer




HDCP 2.2 connection

SFF

C-ENC

SFF

C-ENC

SFF

C-ENC

DBEF Bound Copy

AACS Key Server

Add PKI and .953

methods as options


• Time based release

• Show diagram and description of IBM proposal

• Indicate any player specific information provided to the server

Playback via Online Connection – using correction keys

IBM T

O updat

e and ad

d conte

nt


• Click to edit Master text styles• Second level• Third level

• Fourth level

• Fifth level

IBM T

O updat

e and ad

d conte

ntPlayback via Online Connection – using correction keys


Playback via Online Connection – using PKI


Playback via Online Connection – using AACS

Playback/Binding via Online Connection – using AACS

• As the countermeasure for “Pre-Release Day Availability of Rips”, we currently have On-line function using BD-Live/BD-J (refer to AACS BD Prerecorded Book, 4.6.3 Download CPS Unit Key).

• Also, we currently have Device Binding function using BD-J (refer to 4.5 AACS Media Binding). In case of key download above, Device Binding could be applicable using BD-J.

• Online key download and Device Binding is now optional for disc.

• We need to study if security requirement of current OSPA is adequate for key download.

September 19, 2013AACS Confidential23

Needs

update f

or AACS 2.

0

on-line key delivery With BD-Live

September 19, 2013

AACS Confidential 24

PlayerBD-ROM

Set of Device Keys

Process MKBMKB

KCD

Volume ID

AES_G

AES_G

AES_D

AES_D

Media KeyMedia Key

Encrypted AV Stream

BD-Live Server (for Key Download)

Local Storage

CPS Unit Key FileCPS Unit Key File

(Empty)

AV StreamNeeds

update f

or AACS 2.

0

Device Binding

September 19, 2013

AACS Confidential 25

PlayerBD-ROM Set of Device Keys

Process MKBMKB

KCD

Volume ID

AES_G

AES_G

AES_D

AES_D

Media KeyMedia Key

Encrypted AV Stream

BD-Live Server (for Key Download/Device Binding)

Local Storage

CPS Unit Key File(with MAC of

Device Binding Nonce)

CPS Unit Key File(Empty)

AV Stream Device Binding NonceIntegrity Required

Verify

Device B

inding Nonce

Needs

update f

or AACS 2.

0


Title DiversityTitle Key Server

UHDPlayer




HDCP 2.2 connection

SFF

C-ENC

SFF

C-ENC

SFF

C-ENC

DBEF Bound Copy

AACS Key Server


• Sony presentation (Chris Taylor’s)

• HDR player must be able to report platform information and status

• SW module – initially on disc, but can be downloaded

• Player runs in Trusted Execution Environment

• List capabilities in SW Module – key processing, decryption, forensic WM

• Overlay on AACS core functions (always present because not all discs require on-line connection)

Title Diversity

Chris T

O updat

e and ad

d conte

nt

Separ

ate W

M from

dec

ryptio

n and ke

y

Proce

ssin

g. Sep

arat

e titl

e dive

rsity

capab

ility

From

exec

ution en

vironm

ent


Digital Bridge Export FunctionTitle Key Server

UHDPlayer


Time base release of Title Keys


HDCP 2.2 connection

SFF

C-ENC

SFF

C-ENC

SFF

C-ENC

DBEF Bound Copy

AACS Key Server


• Two approaches

• 1st approach allows DRMs to get licenses and keys from the DRM system

• 2nd approach uses AACS (see Ueda-san proposal from Sony

• All players support at least one of a defined set of output DRMs

• AACS evaluates DRMs for robustness (like MCOT approval)

• Device Keys

• Files transferred are in SFF and use C-Enc

• Manifest determines what is copied

DBEF


Digital Bridge Bound CopyTitle Key Server

UHDPlayer


Time base release of Title Keys


HDCP 2.2 connection

SFF

C-ENC

SFF

C-ENC

SFF

C-ENC

DBEF Bound Copy

AACS Key Server


• Similar to BCM in AACS

• Uses AACS MCAS and MC protocol to enable copy

• Format is BDMV-FE

• Re-encryption not required

• Copy bound to copying machine?

• Bit for bit copy – no manifest required

Bound Copy

Ueda-

san T

O updat

e and ad

d conte

nt

Bound Copy Protocol

4/7/15

AACS CONFIDENTIAL

32

UHD BD Player

UHD BD-ROM

Coupon Code

Local Storage

Payment Server

PMSN

Offer Request

Coupon/PMSN (Optional), Content ID/Device ID

Device Priv Key/Cert

Offer Response

Offer (price info etc.)

Main Title Indicator

Permission Request

Selected Offer ID

Permission Response = Playback license

Permission, Re-enc Key

e.g. Price info, Session ID etc.

ContentsFinancial Transaction

(Optional)

Content ID

Bound Copy

AACS Server

Protocol of Financial Transaction is outside the scope of AACS.

Ueda-

san T

O updat

e and ad

d conte

nt


• Monitor activities of hacker community – The Forensics Lab should monitor all internet activities of the hacker community paying particular attention to English, Chinese, and Eastern European (i.e. Russia) communities. This should include monitoring bulletin boards and internet relay chat (IRC). Note that the countries that are actively monitored may change or added to in the future.

• Test lab facility – The Forensics Lab should have the technical ability to perform the following tasks:

• Tracing of host certificates

• The ability to reverse engineer SW devices and code in order to identify potential security flaws

• Download, test and analyze hacking SW

• Reverse engineer/analyze code used for hacking

• Tracing servers – identify location and number of servers being used to compromise the CP system

• Analysis of hacking organization capabilities – The Forensics Lab should be able to analyze and understand how the hacking tools function, what technologies are used, how the attacks are implemented, where the financial transaction takes place, and related issues

• Analysis of general industry attacks – The Forensics Lab should be able to analyze general types of attacks used by the hacking industry and suggest effective countermeasures.

• Provide analysis of ongoing open source efforts – The Forensics Lab should be able to follow and provide analysis for open source activities

• Tracing of SW versions – The Forensics Lab should be able to trace versions of the SW that have been deployed

• Test includes all techno-forensic info – The Forensics Lab should have the following test capabilities:

• Bus tracing, IDA (reverse engineering tool)

• Systematic testing of platforms

• Market report – the Forensics Lab should provide a market report on the state of the hacking industry on an annual or bi-annual basis

• Downloading content forensically marked to identify the source of the compromised content

Forensics lab (uplevel, less detail)


• Third party certification – AACS approved Authorized Certification Entities (ACE) shall be established that conduct testing of all Licensed Products to validate that those products meet all testable requirements in the Compliance Rules. This is presently being implemented in AACS

• Market Audits – AACS would establish an independent test center to conduct random testing o players currently in the market to validate that those players are compliant with the Certification Test requirements

• Any 3rd party security technology implemented on the client device that may impact AACS security must be certified and that certification is the responsibility of the technology provider

• Watermark technologies

• Security Module provider

Certification


• The system shall have the ability to revoke and renew code signatures if these are used as part of the system’s root of trust

• The system shall have the ability to revoke individual devices or classes of devices

• In the above cases of revocation, the system shall support an alternative that allows access to alternate content or only to existing purchases.

Device Revocation (to be discussed)


BACKUP

AACS 2.0 -1st draft - wikileaks.org 2.0 Architecture... · 4/7/15AACS CONFIDENTIAL2 •Overview &...

Documents

Transcript of AACS 2.0 -1st draft - wikileaks.org 2.0 Architecture... · 4/7/15AACS CONFIDENTIAL2 •Overview &...