Netflix Security Requirements for Android 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 Netflix Confidential 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. Netflix Confidential 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 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 Netflix Confidential 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-migrateability Netflix 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 • 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 Netflix Confidential 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 • 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 Netflix Confidential Content Protection Overview DRM License DRM keys at risk Most important protection (or) decrypt license best attacks here! Encrypted (Compressed) Video Content key at risk Most important protection (or) decrypt content best attacks here! Compressed Decrypted Video Fast, high quality Very important protection (or) ripping decode really great attack here! Uncompressed Decrypted Video Slow, good quality Some protection (or) render ripping minor attack here! Video Frames Netflix Confidential 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. Netflix Confidential 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) • 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 Netflix Confidential 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 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 Netflix Confidential TEE: Abstract Overview Netflix Confidential 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 Netflix Confidential Hardware TEE Example Netflix Confidential 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 • same security properties of closed platform • secure world controls – OTP/keys – internal SRAM – sometimes can isolate/protect decrypted content – “normal world” runs untrusted code Netflix Confidential TrustZone TEE example *copied from “TrustZone: Integrated Hardware and Software Security”, Information Quarterly, Volume 3, Number 4, 2004 Netflix Confidential Numerous ways to Implement TEE (3) • Virtualization – with secure boot, robust hypervisor, and MMU/MPU, functionally equivalent to HW TEE, TrustZone – hypervisor + MMU/MPU enforces isolation of sensitive operations/keys – may meet robustness rules for SD/HD if compressed decrypted buffers are protected Netflix Confidential 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 • 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 Netflix Confidential 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? • 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? Netflix Confidential 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? • 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 Confidential 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 – 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 Netflix Confidential 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 – DRM operations – Netflix protocol cryptography operations – playback pipeline protection • Netflix evaluates specification against robustness requirements, works with partner to close any gaps Netflix Confidential.