Document Sample
Security Powered By Docstoc
					Privacy, Security
And Content
In Windows® Platforms
   Privacy, Security, Content
       Peter N. Biddle, MS
        Technical Evangelist
   MS DRM
       Marcus Peinado, MS DRM Architect
   The Open Trusted PC
       Paul England, MS Architect
A Definition Of Trust

   No matter where my data is, privacy is about
    keeping you from benefiting from access to it
    without my informed consent
       My data can be anything I own and control
        the rights to
       I want to be able to protect it no matter where it is
       Consent is not enough - users need to understand
       Need to provide for the needs of the user first
        while allowing the device to function
A Definition Of Trust
Computer Security

   If my computer holds my data,
    computer security is about keeping
    you from benefiting from
    unauthorized access to my data
       Traditional model of security
       Can include things like
        physical barriers
A Definition Of Trust
Content Protection

   If my computer holds your data,
    content access is about keeping me
    from benefiting from unauthorized
    access to your data
       Your data is anything you own
       You can associate rules with it’s use
       Use encryption, authentication to
        enforce rules
       Need to focus less on preventing access
        and more on allowing access
  There Is No Difference
Between Privacy Protection,
 Computer Security, And
    Content Protection
Did He Really Say That?
   There is no difference between
    protecting someone's privacy
    and protecting someone’s content
   Assurances of trust must be
    universally true
   For anything and everything that
    anyone would want to apply rules to
       A “privacy object” is a
        “content object”
 I Want To Eliminate Our
Ability To Invade Anybody
       Else’s Privacy
Trusted Windows
   Create a platform that will protect
    users from “us”
       This is trust
   Make it extremely difficult to break
    Windows trust
   Technical means are a cornerstone
    of trust
       Technology can protect
        against invasions
       Laws can lock up violators
What Is Piracy?
   Piracy is the un-licensed use of
    someone’s digital property
       Piracy does not automatically result
        in lost revenue
           EG, if I were to make a copy of MS Office
            on a CD-R, and then destroy the CD-R,
            there would be no lost revenue
       Some piracy can even foster sales
        of some kinds of digital property
   Eliminating all piracy is
    prohibitively expensive
       It also pisses off your loyal customers
Does Microsoft Want To Make
Piracy On The Windows
Platform Impossible?
   We are not police officers, nor do
    we play them on TV
   Designing an OS that eliminates
    piracy would be like trying to design
    a car that can’t be used as a
    getaway vehicle
       We don’t know how to do this
       We don’t want to do this
Piracy Comes In Three
 Flavors – Good, Bad,
    And Tolerable
There Is Such A Thing
As Good Piracy
   Piracy that actually fosters more purchases
    of content can be “good”
       There is no easy way to quantify this
   Tolerable levels of piracy are any amount
    that a content owner chooses to sustain
    in order to meet a specific goal
       EG, not pissing off customers
   We want to keep piracy tolerable
    at a minimum
       at a level that allows for sustainable economics
        for all digital content creators
   It is no fun to be a starving artist
Content We Can Protect
From Piracy
   Content that is encrypted or
    scrambled, <and>
   that has rules associated with
    it, <and>
   that requires use of special SW to
   …must be protected.
Content We Cannot Protect
From Piracy
   Unknown Content
       Content that looks “free” to the OS
           Redbook Audio
           Un-encrypted software
       Content that is free to the OS
           ASCII text files
           HTML
       Content we cannot understand
           Content that has been encrypted or
            formatted using proprietary schemes
There Will Be Some
Badness In This World
   Users will have their privacy invaded
   Computers will be hacked
   Content will be pirated
   Our goal is to make these things the
    exception, not the rule
   Create a Trusted Windows Platform as
    trustworthy as the Telephone is today
Protecting Privacy
   HW-based encryption can be used
    to protect documents
   Smart Card that allows users
    to authenticate a PC
       As opposed to now, where a PC authenticates
        a user
   Authentication can allow an end-user to
    verify that a third party is *exactly* what it
    says it is
   Anonymous authentication is even possible
       You don’t know who I am but someone you trust
        does and can vouch for me and my computer
Securing A Platform
   Ensures that a system is what it
    says it is
   Code signing
       Ensures that a legitimate user can’t
        load illegitimate code
       Ensures that an illegitimate user can’t
        load illegitimate code
   Allows a computer and user
    to authenticate themselves
    to a third party
Protecting Content
                  Content has
 Application       hardware, OS,
                   application, terms
     OS           Customers can
                   access the content
                   based on the terms
  Hardware         of the ACL
   Think about these concepts as you
    listen to this session
   Apply them to what you are doing
    in this space
   Two areas of focus in this session:
       What we are doing today to “secure” the
        Windows platform in SW alone
       What we will be doing in the future to
        secure the platform using some
        combination of ubiquitous HW and SW
Digital Rights
Management And Content
Protection Architectures

Marcus Peinado
Digital Media Division
   Digital rights management (DRM):
    fundamentals and vision
       Commerce scenarios
       Security challenges
   Microsoft Rightsmanager
       System features
   Digital rights management (DRM):
    fundamentals and vision
       Commerce scenarios
       Security challenges
   Microsoft Rightsmanager
       System features
E-Commerce / Physical Distribution
 Commerce site
 (Store front)                            customer

 1. Customer selects product                       IE
       (book, CD, DVD, software, hiking boots)
 2. Customer pays                                Card

 3. Merchant ships physical product
E-Commerce / Electronic Distribution
 Commerce site
 (Store front)                                               customer

 1. Customer selects product                                       IE
      (book, audio, video, software, no hiking boots)

 2. Customer pays                                              card

 3. Customer downloads digital content
 4.    customer         friend
E-commerce / electronic distribution /
Digital Rights Management

0. Content owner specifies how
   content may be accessed (off line)
Commerce site
(Store front)

1. 2. 3. Customer selects content
   (book, audio, video) and access
   option, pays, downloads content
4. DRM system tries to enforce
   access rules
DRM: General Model
   Content owner specifies how the
    content may be accessed
   Access specification will be
    enforced subject to the overall
    security level of the system
   Access specifications enable
    business models (e.g. pay-per-view,
    rental etc)
   Compare with Pay-TV schemes
   Digital rights management (DRM):
    fundamentals and vision
       Commerce scenarios
       Security challenges
   Microsoft Rightsmanager
       System features
General DRM Goal
   Traditional PC security: Protect a
    good host from a hostile application
   DRM security: Protect a trusted
    application in a hostile
    host environment
       Adversary has full physical control
       Plaintext content must be accessible
DRM Core
End-user PC

 components    Requirements:
               1. Secret hiding
 application   2. Secure execution
               3. Verification of
DRM Client        other components
Building Upon 1,2,3
   Assuming that primitives 1,2,3 are
    available, a secure content
    protection system can be built
    using standard cryptography
Implementing Primitives 1,2,3
   Known approaches:
       Secure hardware (e.g. Secure
       Tamper resistant software
       Security by obscurity
   All known protection methods can
    be corrupted by a sufficiently
    powerful adversary
Adversary Models
   Naïve: will copy files (mp3); may be
    willing to install hacked programs;
    will not actively hack
   Skilled: in-depth knowledge, but no
    commercial interest; will break most
    software protection mechanisms
   Professional: pirate corporation;
    commercial interest and funds to
    hire skilled pirates; may reverse-
    engineer hardware protection
   Fundamental Law of Anti-Piracy
       Any given content protection
        component (software, hardware) will
        be subverted by a sufficiently
        powerful adversary
   Parameters:
       Value of the protected assets
       Time until break
       Resources of attacker
   Allow easy recovery from breaks
       Disable / Revoke broken components
           Revocation of DRM clients
           Revocation of processing components
       Field upgrade to re-enable the system
   Individualization to
       Reduce scope of individual breaks
       Improve granularity of revocation

DRM             PC
Renewability: 1. Deployment Of DRM

DRM                                  PC
Renewability: 2. Attack On DRM

DRM                              PC
Renewability: 3. Distribution Of The Break

DRM                                    PC
Renewability: 4. Revocation And
Field Upgrade

DRM                               PC
Other Challenges
   Secure time (expiry)
   Secure state information
    (e.g. counted play)
   Recovery from catastrophic failure
   Standard deployment mechanisms
    and global secrets
   Working with external
    system components
   Cannot write unbreakable software
   Aim to limit the effect of
    individual breaks
   Aim for cheap recovery
   Configure security parameters
    based on what is being protected
    and against whom
   Use cryptography to reduce the
    number of weak spots
   Digital rights management (DRM):
    fundamentals and vision
       Commerce scenarios
       Security challenges
   Microsoft Rightsmanager
       System features
WM Rightsmanager: Goals
   Bring premium audio/video content
    to the Windows platform
   Content owners (Hollywood) want
    protection for their content.
   Enable a whole range of new
    software applications
   Non goal: control of the end user’s PC
WMRM: General Features
   Works with ASF/WMA
       Audio,
       Video,
       Illustrated Audio
       Any Codec
       Core DRM is “Media Agnostic”
   Streaming and Download
   Portable devices, portable media
   Client
       Free web download
       Part of Windows Media Technologies
       100 million downloaded clients
   Server
       Free web download
       Register with Windows Media
       Used for audio and video distribution
        by a variety of companies
Usage Scenario: Promotional
   “Know your audience”
   Distribute promotional
    trailer (encrypted)
   Give license to users in exchange
    for email address etc.
   Superdistribution; put trailer on
    empty space of existing CD or DVD
   DRM forces each user to obtain
    a license from the server
Sale, Rental, Pay Per View
   User obtains encrypted content
       Download
       Streaming
       DVD
   User contacts clearing server and
    makes payment
   Usage rules specify user access
       Simple in DRM V1
       Much more expressive in the future
                                  Content (plaintext)
                                                                           sound card
      Hosting Server              2
      1.    Encrypts content
      2.    Allows download

                                  t       Content (encrypted)   End-user machine
                                  o                         3
shared secret
                   1              r                             WMPlayer

                                  e                                7      Authentication
     Clearing Server              f
     1.    Authenticates client           License request   4
     2.    Generates license
                                  r                             DRM
                                  n        License (key)    5
                                  t                             Content
      Hosting Server                    S                                        Monitor
                                                                                 sound card
      1.    Encrypts content
      2.    Allows download
                                        o                            End-user machine
                                              Content (encrypted)    Downstream
                                        e                            components
shared secret
                                                                     DRM Client
 Clearing Server                        r
                                                                        License acquisition
 1.   Authenticates client              o                               Crypto engine
 2.   Generates license
                                        n      License acquisition
                                                                        License evaluation engine
                                                                         Authentication engine
                                        t                            

                                                                        Hardware binding

  Central DRM services                                  Code
          Client certification / initialization
          App authorization / control                                           Portable devices
          Server authorization                                                  Portable media
          Backup / restore
DRM Client Architecture
                     Rendering Application
 content                                     Request rights (play)

                                      DRM Client
                     Content crypto                 Authentication
                     engine                         engine

                      License                  License eval
                      acquisition              engine
(from lic. Server)
                     License store         Secure        Hardware
                                           state         binding
   Goal: Protect the DRM client
    against global attacks
   Registration with DRM server
    on installation or first use /
    field upgrade
   DRM server provides per-client
    keys and code
Individualization /
Field Upgrade
                                                             User Machine
  DRM Server
     Certification                 Upgrade request                         uniform
     Individualized dll                                           DRM


                            dll                       “This license           License
Install DRM                certs
                                                      requires an
                                                      individualized          request
Local CD ripping
Remote license acquisition
Upgrade trigger
Upgrade request
                                                                 License Server
Server generates indiv. dll
Install on client
End-To-End Channel
   Audio / Video content flows through
    many processing components
    (renderer, sysaudio, sound card
    driver etc)
   Content can be extracted from any
    of these components
   Task: Retrofit DRM onto the existing
    audio / video infrastructure
   First step: Windows ME
Secure Audio Path
                       Audio Components

                                           SysAudio     4.

                                DRM-K       Remove      5.
             DRM           2.
           Add noise              3. verify Kmixer, …
                         user kernel      AudioDriver 6.
Secure Audio Path
   License triggers secure audio path
   Verify components(WHQL
    sig,DRM bits)
       Below KMixer
   Disable digital loopback in audio driver
   Noise for tunneling through to Kmixer
   Certification of external components
    through existing WHQL process
       Requires small piece of new code
        (100 lines)
Content Encryption
   Fast
       10 Megabytes per second
       Allows encryption of the entire
        video signal
   Fault tolerant
       Packet based: tolerates loss of
        arbitrary set of asf packets
   Secure
       Full-strength encryption algorithm
header   Data
                       Content Encryption

                                                    asf file

                  All payload packets are fully encrypted
                  Each packet is encrypted individually
                  No increase in packet length

                                                     asf file
   DRM Goals:
       Bring premium content to the platform
       Enable new business and
        distribution models
       Enable new applications, which
        process this content
   Security:
       Baseline DRM client
       Renewability, individualization
       End-to-end channel for audio, video
The Open Trusted PC

Paul England
Microsoft Corporation
Strategic Software and
Platform Technologies to make
the Open-PC as Trustworthy as
the Closed-Box, for
    User Privacy Protection
    Rights-Managed Data
   The Trusted PC Paradox
   Platform Authentication
   Authenticated Boot
   Privacy Protection
   Secure Persistent Storage
   Summary
The Trusted-PC Paradox
   The PC is open – anyone can add
       Any software
       Any hardware / option ROM
       Any operating system
       Any BIOS
       …
   So how can it possibly be as
    trustworthy as a closed box?
   It’s very hard to store secrets on a PC
   Many viruses have more rights than
    the user
   Even if an OS secures (using ACLs)
    files or data for users
       No other OS needs to honor these
        access controls
           All file systems are readable under all OSs
Contrast This With
A Closed Box
   E.g. set-top box, game-console,
    other CE-device
       Can’t add third-party hardware
       Can’t add unauthorized
        third-party software
   How can we achieve the best
    of both worlds?
Targeted Audience
   Not just professionally
    administered machines
       Home PCs
       Small businesses
       Laptops
       Corporate client machines
        (dial in + desktop)
Long-Term Goals
   Growth of the Web Lifestyle
       More e-commerce
       Greater use of Web-services
       More of your personal and
        valuable information
           On your home PC
           On Web servers

        Increase trustworthiness of your PC
        and provide mechanisms to allow you
        to determine trustworthiness of the
        Web-services that you use
Platform Authentication
We propose adding platform HW/SW to
  reliably report the platform configuration
 User can boot into a system that can
  reliably report its configuration
 A Web-site can do this to “brand trust”

 A home-user can do this to obtain
  premium content
 A corporate user (RAS, or intranet) can
  do this to gain access to the network
     The user must always be in control of what
     information she reveals
Corporate RAS Access
                   requires Win2K
                     + Certified
                      drivers to
                   access network

    n hardware
     can prove
    client boot-
Another Example
 Doctor’s PC          Doctor’s office PC
                           is not
                                               Insurance company
                                                 wants to check
                                             trustworthiness of the
                                                doctor’s PC before
                           Insurance            revealing records
                           challenges PC
                           to authenticate
   Trusted                                      Medical Insurance
   Platform                                     Company

             Doctor’s PC responds by
             describing its configuration
Authenticated Boot
   PC will boot any software and the
    OS can run any policy, but…
       The platform reports the booted
           (we will require privacy support)
       ISVs (OS-vendors) can choose what
        kind of information they reveal
   This is not secure boot
       Platform can still boot any
Design Considerations
   We need additional
    security hardware
   There is no way (right now) that a
    challenger can reliably distinguish
    WinME from Win2000
   The additional hardware should add
    minimal cost, and minimally perturb
    the PC boot /execution model
A Simple, Cheap, Solution
   Platform crypto-processor
       E.g. “smart-card core”
   Small changes to BIOS
       BIOS “reports” platform configuration
        to crypto-processor
   Small changes to OS-boot model
       E.g. only load signed drivers
   Some changes to OS execution model
Simplified Authenticated Boot
                   Driver1     Driver2   Driver3



   Trusted BIOS “logs”          Boot log     crypto-
   the digest of the OS-        OS-loader
   loader that it passes                    processor
         control to
Simplified Authenticated Boot
   BIOS Loads an OS-loader
   OS writes the digest of the loader
    into a write-once protected area
   OS-Loader (typically) contains a
    public key or certificate
       OS-loader only loads drivers that
        it trusts
           They are certified by the loaders CA
       Any ISV can write any OS-loader
        using any load policy
Platform Authentication
   Protected log contains the
    OS-loader digest
                                      Kernel Component
     Hash of all      OS-Loader
       of OS-
      loader is    Load-Policy Code
     written to
     the write-
      once log                         “Authenticode”
                    Publisher Root       Certificate
Configuration Reporting
   Write-once log contains a hash that
    represents the running OS
   How can we use this?
       Not much use to just “tell”
        a challenger
           It’s a well-known number
   We use cryptographic reporting
       The crypto-processor can report the
        configuration using a secret key
       The QUOTE operation
The QUOTE Operation
       SIGN(challenge, boot-log)
       Challenger sends a “nonce”
   Platform responds with a signed
    description of the boot
    configuration + nonce
   Challenger can decide whether
    to allow access
    other mechanisms provide for privacy –
       see later
Adding Flexibility –
The Boot Policy File
                                             Boot Policy File

         Loader loads and logs             Publisher Root Cert
           the boot-policy file          Exceptions (revocation)
                                            Other boot-policy
              Loader obeys the                    Date
              Policy description
                                             IT or Publisher

records OS-           Secure Log        OS-loader records
   loader             OS-loader        Boot-policy in effect
                    Boot policy file
A More Complicated Example
   Practical boot models must include
    OS-selectors, etc
   Use the same basic model –
       Measure component about to
        execute next
       Decide whether it is “trustworthy”
           If it is, do nothing
           If it is “unknown,” securely log its “digest”
       Pass control
How Do We Implement The
Secure Log?
  What we would like:            +
                           Similar logs for
                        firmware, microcode,
                        upper-level software,
     OS-boot-sector             etc…
       Boot Policy
                        How can we do this
     Virus definition
                          cheaply (and
EXTEND Simulates
An Infinite Secure Log
   EXTEND operation + one
    secure register
       EXTEND(d)
           Takes current contents of register
           Hashes it with d
           Stores it back in the register
   Hashing is one-way
       Nobody can figure out how to
        “remove” an entry
                             Platform executes
        MBR                  1) EXTEND(MBR)
                             2) EXTEND(boot-sector)
                             3) EXTEND(Boot-policy)
    Boot Policy
                             4) EXTEND(virus defn)
   Virus definition
                             5) EXTEND(…)

   Challenger needs to do a little more work to interpret
          the composite value– but it is not hard
Authentication Model
   Suppose we have a certified key-
    pair in the “crypto-processor”
   You can tell anyone what platform
    you are running, but…
       This is like a “super-cookie” you
        use everywhere
       Unscrupulous sites could track what
        you are doing
   This is not an acceptable solution
Authenticated Anonymity
   Users can acquire
    anonymous identities
                                             Trusted      Trusted
        Platform key                         Identity     Identity
                                              Server       Server

    Banking      ISP       Corp.
    Identity   Identity   Identity                      User picks
                                     Bank Web Server    an Identity
                                                        trusted by
                                                         bank and
Other Considerations
   Identity acquisition is fully opt-in
   Pick (during-boot) whether OS
    should support authentication
       Nothing wrong with being anonymous
Boot Complications
   Boot is multi-step
       MBR, OS boot-sector
   BIOS is typically flashable
   Many option-ROMS insert code
   Favored model is
       Provide logging for all components
        that affect trust
       (Not all challengers will care)
Other Implementations
   Chipset model
   Removable token
   Processor changes
Secure Persistent Storage
Motivation (I)
   You want your “Trusted OS”
    to store your banking records
       But another OS can always read
        the files…
       Simple encryption doesn’t help
        (where do you store the keys?)
       Password-protection doesn’t
        really help
Secure Persistent Storage
Motivation (II)
   When you RAS-in to your
    corporation you can prove you are
    running a Trusted-OS
   But, on a dual-boot Machine
       Where do you store files that are not
        accessible to viruses on another OS?
       Where do you store files that are not
        accessible to users on a cable-LAN if
        the other OS is badly configured?
Secure Persistent Storage
Motivation (III)
   Premium content providers provide
    rights-managed content to
    Trusted Platforms
       How can a trusted platform store this
        data for users?
   We want the Trusted-PC to be the
    favored platform for rights-
    managed goods
Sealed Storage
   Trusted Platform can store secrets
    for other “named configurations”
       Boot into a named configuration, you
        get to decrypt the secrets
       Boot into a different configuration and
        you can’t recover the decryption key
   Any Trusted OS can store secrets
    for itself or name other OSs
   We build on the same configuration
    log we collected during boot
   SEAL(secret, log-value)
       Uses a platform secret key to encrypt
           {secret, log-value}  Blob
   UNSEAL(Blob)
       Internally decrypt
       Return “secret” if platform is in the
        named configuration
SEAL Usage
   SEAL is mostly used to save encryption
    keys for registry hives / EFS keys
   Mostly the OS “names itself” as trusted
    to decrypt
       Can name other OSs
       Can name an upgraded OS
Other Uses For SEAL
   Simplifies deployment of
    Trusted Platforms
   Authenticate the platform once,
    then SEAL
       Your network logon keys
       Your home banking keys
       The Win2000 domain logon key
       Any privacy-sensitive data
   With SEAL we can do a better job
    of protecting users secrets
Other Uses For SEAL (II)
   EFS Keys
       Encrypted file-systems need per-user
        or per-platform storage keys
       We can improve security of keys for
           Dual-boot machines
           Laptops
           Shared use home-machines
Summary: QUOTE
   QUOTE allows the platform
    configuration to be reported
    when online
   SEAL / UNSEAL allows platform
    configuration to be inferred when
    online of offline
   Trusted Windows Technology
       Enables the best of both worlds:
           Trusted, Open Platforms
   Need new platform hardware
    to achieve it
       Changes are not costly or profound
   Trusted Windows is the Platform
    for the future of E-commerce
Calls To Action
   Platform Trust
       Join TCPA
   Content
       Join SDMI
       Join CPTWG
   Privacy
       Join TrustE
   Talk to us!

Shared By: