Transcript slides

Digital Rights Management and
Trusted Computing
Kari Kostiainen
T-110.7200 Special Course in Operating System
Security
April 13th 2007
First paper:
Enabling fair use with trusted computing
(unpublished draft)
Motivation
• Good DRM system should enable various use cases
• Listening a song three times before purchase
• Renting a movie so that it can be watched only once
• Moving a purchased song from one device to another
• Enforcing this kind of stateful licenses is difficult in open platforms
• Reverting the system to a previous state is easy  the movie can be watched again
• Existing solutions are not satisfactory
• Obfuscation and rootkits
• Online solutions
• Dongles and smardcards
• This paper presents an architecture that enables enforcement of stateful licenses
on open platforms using trusted computing
Security objectives
• License integrity and enforcement
• All parties must enforce licenses and unauthorized alteration must be infeasible
• Freshness
• Replay-attacks must be infeasible
• License availability
• Usage without online connectivity must be possible
• Privacy
• The system should preserve users’ privacy
System model
• Strong isolation between compartments
• Trusted channels bound to configurations of compartments
• In principle all compartments could be located on different machines
Implementation
• Hardware layer: normal PC hardware with TPM
• Virtualization layer: based on L4-family microkernels (Xen could be used as well)
• Trusted software layer: based on PERSEUS security architecture
• Application layer: legacy operating system (para-virtualized Linux) and security critical
applications
System startup
• Normal TPM-based boot sequence
• BIOS measures master boot record (MBR) before giving control to it
• MBR measures kernel before giving control to it
• and so on…
• Uses modified GRUB boot loader
• The Compartment Manager (CM) measures other compartments, legacy
operating systems and applications before executing them
Establishing trusted channels
Verify signature
using AIK
RC compares to
known
comp_confLC and
TCB_conf
RC creates a
secret key sk
TPM creates
PKBIND and
SKBIND
TPM creates
certBIND using
AIK
TM verifies that
comp_confLC is
same
TPM verifies that
TCB_conf is
same
Secure storage overview
• Storage Manager maintains metadata index that logs usage of securely stored items
• To maintain freshness the index also manages a software counter that is incremented
synchronously with TPM 1.2 monotonic hardware counter
 Provides protection against attacks that try to revert into previous state
Using secure storage
Sealed against
TCB
configuration
Same TCB
configuration
TPM counter
check missing?
Second paper:
Enabling advanced mobile DRM scenarios
N. Asokan and Jan-Erik Ekberg
Example use case
• Timo has purchased a song using his mobile device
• Anna would like to listen the song as well
• Timo transfers the song to Anna’s device for limited free listening
• If Anna wants to continue listening she must commit to purchasing the song for
herself
• Constant online connectivity should not be needed
• How to implement a system like this that provides flexible and fair use of
purchased content without allowing unauthorized use?
Conceptual architecture
• DRM device is a tamper-resistant module
• Protocol engine contains the actual DRM enforcement logic
• Different payment methods can be plugged into this architecture
Types of rights and transfers
• Each piece of content has two types of rights
• Usage rights that govern local use
• Transfer rights that specify how new rights can be created for different devices
• Different kind of transfers are possible:
• Give: once the right is transferred the original device cannot use the content anymore
• Copy: a new right is created for the new device
Vouchers determine rights
• Each piece of content is encrypted with a content key
• Rights for a piece are embodied in a voucher that contains
• Description of content
• Description of rights
• Content key encrypted using public key of target device
• Sequence number for freshness
• MAC for integrity
• When rights are transferred the sending device creates a new voucher for the
target device
• Sending device must check that target device is compliant
Metering and reporting new rights
• Creation of new rights must be metered and reported
• Otherwise, unauthorized copying could take place
• New created right can be either sender-reported or receiver-reported
• Preview vouchers are special case of receiver-reported voucher
• Unreported voucher is marked as report-pending
• When a proof of reporting is inserted into device, the report-pending voucher is
converted into an unconstrained one
• If the number of report-pending vouchers exceeds a certain limit, the device could
be disabled in some fashion
Lifecycle of vouchers
Rights transfer protocol
Requirements from platform
• The user cannot make modifications in the OS kernel
• OS processes cannot access each other’s memory areas
• Small tamper-resistant secure storage for kernel which can be used to bootstrap
larger secure storage
• Process claiming to be DRM engine must be authenticated
• Integrity checks could be used
Implementation
Own thoughts about these paper and DRM in general:
Own thoughts
• The DRM system should be flexible, so that users can consume legally
purchased content on all of their devices
• This means that all devices should be compliant  all devices should have TPM
or something similar
• Will device manufacturers put TPM to 20 € MP3 player?
• I don’t think so
• Thus, these schemes do not seem promising for music
• If TPMs get very popular in PCs use cases like enforcement of software license
or video rental might work
• But even then it would be difficult to get all audio and video device drivers accepted
Thank you!