1 / 17

Building Secure, DRM-Enabled Devices

Building Secure, DRM-Enabled Devices. Avni Rambhia Program Manager John C. Simmons Program Manager Strategic Relations & Policy Windows Client Division. Session Outline. Introduction The importance of secure DRM implementations

Download Presentation

Building Secure, DRM-Enabled Devices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Building Secure,DRM-Enabled Devices Avni Rambhia Program Manager John C. Simmons Program Manager Strategic Relations & PolicyWindows Client Division

  2. Session Outline • Introduction • The importance of secure DRM implementations • Anatomy of robustness rules – content, assets and security levels • The general threat surface for DRM-enabled devices • The design of secure DRM-enabled devices • Protecting device assets • Device asset threat surface and robustness rules • Robust hardware, firmware and software best practices • Protecting controlled content • Controlled content threat surface and robustness rules • Best practices for robust protection of controlled content • Design pitfalls to be avoided • The secure development environment • Call to action • Questions and answers

  3. The Importance Of Secure DRM Implementations • Secure DRM technology is required for access to valued content • Access to valued content can be denied to implementations which do not meet robustness rules • After deployment, access can be revoked for implementations which are shown to violate robustness rules • The robustness requirements for DRM-enabled devices are likely to increase with the value of deployed content

  4. Robust Hardware-Firmware Best Practices • Robust hardware design • Put critical data bus traces below the surface of the board • Use a highly-integrated chip design or high-density packaging • Use on-chip RAM to secure keys during decryption • Use a CPU that supports segment-level cache locking • Support the use of a Smart or SIM card • Use chassis tamper-detecting hardware • Robustness and manufacturability • Disable all on-chip debugging resources in production • Do not run Security Functions with JTAG-enabled hardware • Cover Test Points with Epoxy • Robustness and device tamper-resistance • Establish a secure platform, based upon one strong root of trust • Extend chain of trust to the software applications running on the device • Don’t run security functions if environment does not match production specifications

  5. Robust Software DesignBest Practices • Robust software design • Use high resolution performance timer to detect kernel level debuggers • Link select C runtime code directly into your binary • If keys must be held in virtual memory, lock the key in memory • Minimize the time that secrets are kept in the clear in memory • Verify compiler optimizations do not undo your buffer zeroing operations • Scrub memory which has contained secrets before passing to free() • Robustness and device key concealment • De-randomize key information when obfuscating it in storage • Ensure that the obfuscation algorithm is one-way • Obfuscate key information in a binary object at least 1 KB in size • Robustness and the product life cycle • Use a program obfuscation tool to frustrate reverse engineering attempts • Exclude private key concealment software from pre-release devices • Enforce physical access and security rights to all code during production

  6. Best Practices For Robust Protection Of Controlled Content • Integrate components whenever feasible • If asset must flow over a bus • Provide cryptographic protection to the asset (not 'unprotected') • Provide structural protection to the bus (not 'accessible') • Minimize vulnerability to peripheral attacks. Examples • use non-paged memory when feasible • use design with on-chip RAM whenever feasible • do not buffer structured cleartext compressed content to one memory chip • minimize time for which clear asset is in process memory • Provide layered protection for assets in storage • Layer 1: Cryptographically protect the content key • Layer 2: Obfuscate the secret which protects the license • Layer 3: Obfuscate the code which extracts this secret

  7. Design Pitfalls To Be Avoided • Not verifying/tamper-protecting root public keys • Not protecting the key that protects the key • Seeding a robust pseudo-random number generator with poor entropy • Ignoring bus vulnerabilities in a System-on-Chip design • Not incorporating threat modeling as part of thedesign process • Designing to today’s industry requirements/constraints, without consideration of the future • Not incorporating security into the development and manufacturing process

  8. Secure Development Environment • Enforce physical access and security rightsto security code • Access and use policy around secure code • Secure lab for Device key development • Control access to Device key design documentation • Control access to Device key source code • Build the Device key software on a secure machine • Manufacturing security • Never expose device secrets in the manufacturing environment • Make sure repair instructions do not inadvertently leakconfidential information • Ensure mechanical restrictions imposed by Robustness rules are met by post-repair devices

  9. Call To Action • Understand all compliance and robustness rules requirements for your device before beginning thedesign process • For example, the compliance and robustness rules for Microsoft’s next generation Windows Media DRM for Portable and Network Devices • Anticipate future trends in robustness requirements by discussing with Microsoft, content providers, andchip manufacturers • Perform threat modeling at all stages of the design process – make asset protection and content protection integral to your design process • Audit your development environment and manufacturing process for vulnerabilities

  10. Additional Resources • Email • Secdrm @ microsoft.com • Web Resources: • WM DRM Web Site: http://www.microsoft.com/windows/windowsmedia/drm.aspx • WM DRM Partners • http://www.microsoft.com/windows/windowsmedia/drm/9series/providers.aspx • Windows Media Community • http://www.microsoft.com/windows/windowsmedia/community.aspx • Windows Media DRM Newsgroup • news://msnews.microsoft.com/microsoft.public.windowsmedia.drm • Related Sessions • Business Opportunities with WM DRM (SW04004) • Designing Portable Media Players for Windows (TW04050) • Media Transfer Protocol (TW04083) • Windows Media Connect (TW04081) • Certified Output Protection Protocol (TW04066) • Next Generation Windows Media DRM for Consumer Electronics Devices (TW04014)

  11. Community Resources • Community Sites • http://www.microsoft.com/communities/default.mspx • List of Newsgroups • http://communities2.microsoft.com/communities/newsgroups/en-us/default.aspx • Attend a free chat or webcast • http://www.microsoft.com/communities/chats/default.mspx • http://www.microsoft.com/seminar/events/webcasts/default.mspx • Locate a local user group(s) • http://www.microsoft.com/communities/usergroups/default.mspx • Non-Microsoft Community Sites • http://www.microsoft.com/communities/related/default.mspx

More Related