netflix security requirements android platforms - wikileaks platform... · netflix security...

Netflix Security Requirements

for

Android PlatformsAndroid Platforms

Version 1.0

December 6, 2010

Netflix Confidential

Overall Security Philosophy

• Netflix and Partners are working together to create a market for connected

platforms and services

• For long-term success, this requires a healthy and secure ecosystem

– Based on best practices

– Transparency between content, service, and platform partners

– Proactive cooperation, rapid response

• Our mutual success depends on it

– Breaches hurt everyone


Typical Studio Requirements

• Platforms must meet agreed-upon robustness specifications (Netflix

Robustness Rules, DRM providers’ robustness rules)

• Platform partners must submit sample products and security

documentation to Netflix for certification.– Netflix must review documentation and assess compliance with robustness

specifications

• If a platform is breached, Netflix or partner may be required to revoke

individual or class of platforms.

• In case of extended breach or platform non-compliance, studio has option

to suspend availability of content to the Netflix service.

– Such action would adversely affect all platforms and all Netflix subscribers.


Android vs. Studio Requirements

• Most Android platforms have been “rooted”

– yields full control of system

– history suggests this problem will not go away

• Once rooting occurs, Linux security model is insufficient to

protect content-related assetsprotect content-related assets

• Without modification, these platforms do not allow Netflix to

meet contractual obligations to studios

• We are aggressively working with partners to address this

vulnerability


High-Level Platform Security Concerns

• Content Protection

– DRM keys

– Content keys

– AV content

• Application Security

– Application keys

– Access to Netflix APIs & functionality

– Non-modifiability

– Non-migrateabilityNetflix Confidential

Content Protection: DRM Keys

• Group key

– typically provisioned in manufacturing

– one key for entire class of devices (e.g. model)

– signs self-generated device certificates (it’s a CA key)

– this is a very-high-value asset– this is a very-high-value asset

• Device key/certificate

– typically self-generated by device, signed by group key

– used in DRM license transactions

– provides access to content keys

– this is a high-value asset


Content Protection: AV Content

• Content key

– used to decrypt content packets

– because encrypted content is hosted by CDNs, these have a long

lifetime

– with content key and matching URL, can download and decrypt

premium content title

– this is a high-value asset– this is a high-value asset

• Content

– decrypted, compressed content has moderately high value

• can easily export regardless of local processing/encoding power

– uncompressed content has lower value than compressed content

• harder to export (depending on system)

• system may not have high-speed encoding capability

• if a 90-minute movie takes 6 hours to rip � not so interesting to attacker

• if platform supports high-speed encoding, more of an issue


Content Protection Overview

Encrypted (Compressed) Video

decrypt contentMost important protection (or)

best attacks here!

Content

key at risk

DRM License

Most important protection (or)

best attacks here!

DRM keys

at riskdecrypt license

Netflix ConfidentialNetflix Confidential

Very important protection (or)

really great attack here!decode

renderSome protection (or)

minor attack here!

Compressed Decrypted Video

Uncompressed Decrypted Video

Video Frames

Fast, high

quality

ripping

Slow, good

quality

ripping

Application Security: High-Level Objectives

• Protect Netflix application keys

– Not as valuable as DRM keys, but must be protected to a suitable level

• Protect access to Netflix APIs and functionality

– Only authorized code/scripts allowed to access Netflix specific APIs

• Protect application against modification (runtime or static)

– Attackers must not be able to arbitrarily modify Netflix binaries for own

use

• Non-migrateability

– Application can’t be moved to less-restrictive generic x86, in VM, etc.


Meeting Application/Content Security

Objectives

• Content and application security are a function of execution

environment security/trust

• Abstractly, we require assets and selected application

elements to reside in a “Trusted Execution Environment” (TEE)elements to reside in a “Trusted Execution Environment” (TEE)

• May not be practical to protect some elements in TEE (e.g.

application APIs)

• TEE can be realized in various ways, with relative trust level

varying depending on implementation details


Defining a TEE

• Provides the hardware/software controls required to

meet robustness requirements

• Required Properties

– Meets minimum required robustness levels in face of attack

• protects DRM keys• protects DRM keys

• protects content keys

• protects content

• protects Netflix keys/credentials

– Facilitates revocation/renewal in case of breach

• provides unique and robust platform identification

• binds application to platform


TEE: Abstract Overview


Numerous Ways to Implement TEE

• Closed platform

– typical CE streaming device

• secure boot, secure update, strictly controlled firmware

– no console, no native binary installation

– generally requires professional tools, skills to subvert

• Semi-closed platform w/multiple cores (hardware TEE)

– sensitive operations run on “security” core

• same security properties of closed platform

• security core controls

– OTP/keys

– internal SRAM

– sometimes can isolate/protect decrypted content

– “application” core runs untrusted code


Hardware TEE Example


Numerous Ways to Implement TEE (2)

• Semi-closed platform w/TrustZone

– secure/non-secure world abstraction supported by

hardware

– processor can switch into protected “secure world” mode

– sensitive operations run in “secure world” mode– sensitive operations run in “secure world” mode

• same security properties of closed platform

• secure world controls

– OTP/keys

– internal SRAM

– sometimes can isolate/protect decrypted content

– “normal world” runs untrusted code


TrustZone TEE example


*copied from “TrustZone: Integrated Hardware and Software Security”, Information Quarterly, Volume 3, Number 4, 2004

Numerous ways to Implement TEE (3)

• Virtualization

– with secure boot, robust

hypervisor, and

MMU/MPU, functionally

equivalent to HW TEE,

TrustZoneTrustZone

– hypervisor + MMU/MPU

enforces isolation of

sensitive operations/keys

– may meet robustness

rules for SD/HD if

compressed decrypted

buffers are protected


Numerous Ways to Implement TEE (4)

• Software TEE

– Challenge is in providing effective isolation between trusted

and untrusted elements

– Tools that can help:

• rigorous obfuscation techniques

• white-box cryptography• white-box cryptography

• anti-debugging techniques

• runtime tampering/integrity checks

• policy/containment framework (e.g. SELinux, grsecurity)

– Software TEE can always be defeated by an attacker with

enough time/motivation, but may be sufficient for

protecting most content


TEE and Android

• Properly implemented TEE provides foundation for meeting

Netflix security requirements with Android-based platform

• Whether a particular implementation is sufficient comes down

to platform design questions:

– Can TEE isolate secure store from Android?– Can TEE isolate secure store from Android?

• implies exclusive TEE access to OTP/keys

– Can DRM operations be isolated in TEE?

• cryptographic operations relating to license acquisition, content key

management/use must run in secure environment

– Can all Netflix cryptographic operations be isolated in TEE?

• NCCP encryption/decryption run in secure environment

– Assuming Android is rooted, how much of playback pipeline can be

protected?


TEE and Android, cont.

• Even with robust TEE, some assets may be difficult to

protect

• How do we adapt Netflix robustness requirements to

this reality?this reality?

• Studios have generally traded increased risk for

reduced content quality (HD�SD)

– we think this can be used to accommodate some design

choices/constraints


Netflix Robustness Requirements for SD/HD

• Minimum requirements for SD

– TEE protects DRM credentials, content keys, Netflix keys

– protect decrypted, compressed content

• if not in TEE, requires kernel-enforced memory isolation

• partner acknowledges and accepts risk of platform revocation

• Minimum requirements for HD• Minimum requirements for HD

– meet all SD requirements

– provisioned with device-unique credentials (e.g. Kpe/Kph)

– TEE protects decrypted, compressed content

– protect uncompressed content

• if not in TEE, requires kernel-enforced memory isolation

• partner acknowledges and accepts risk of platform revocation


Approval Process for Android Platforms

• Choose TEE architecture based on platform

characteristics (hardware, software, or hybrid)

• Based on quality target (SD vs. HD), determine best

way to implement

– secure store– secure store

– DRM operations

– Netflix protocol cryptography operations

– playback pipeline protection

• Netflix evaluates specification against robustness

requirements, works with partner to close any gaps


netflix security requirements android platforms - wikileaks platform... · netflix security...

Documents