Transcript IBM xCP Cluster Protocol IBM Presentation to Copy Protection Technical Working Group

xCP Cluster Protocol
IBM Presentation to
Copy Protection Technical Working Group
July 18th, 2002
IBM
Florian Pestoni
IBM Research
[email protected]
1
Key points

Designed specifically for home networks



Compliant with CPSA


Implements notion of “authorized domain”
Devices with different capabilities, protocolindependent, support for intermittent connectivity
Chain of solutions based on licensing, usage rules
Peer-to-peer, based on broadcast encryption

More efficient and secure
2
Content Lifecycle
Broadband
Distribution
Content
Management
Content
Creation
Digital
Broadcast
Physical
Media
Playback
Home
Gateway
Device
Portable/Car
Playback
MP3
Device
player
Playback
Set-Top Box
Device
Entertainment
Playback
System
Device
3
Content Protection Lifecycle
Watermarking
Tamper-resistent
environment
Broadband
Distribution
Encrypted
content
Content
Management
Digital
Broadcast
Physical
Media
Content
Creation
Home
Gateway
Playback
Device
Playback
Device
Key
Management
Playback
Device
Forensics
4
Usage scenarios

Home entertainment network


Portable


Multiple physical clusters
Party


Connect, download, disconnect
Summer home


Distributed storage, remote playback
Content temporarily available
Marriage
5
Flexible model

Vision


Virtual device


“Make it easy for a consumer to access all her
licensed content from all her devices, but make it
hard for her neighbor.”
Think of a network of (physical) devices as making
up a single (virtual) device
Must limit size

Avoid the “million-device cluster”
6
Broadcast Encryption

Algorithmic Lineage



Alternative to Public Key Encryption



Broadcast encryption - Fiat and Naor, Crypto ’93
Tracing traitors - Chor et al., Crypto ’94
2 or 3 orders of magnitude less overhead
One-way protocols lead to more robust
implementations
Supports key revocation

Unlike global secret schemes in which a single
hacking event breaks the whole system
7
Broadcast Encryption Basics

Device keys


Key Management Block


Each device is assigned a unique combination of
keys
Any device with valid device keys can process KMB
to obtain key-encrypting key.
Binding Key

Key-encrypting key is combined with binding
identifier, (hash of) usage rules, etc.
Skip details
8
Key Management Blocks


Scheme is large matrix of random keys
Each device assigned one key from each column
EKi,j(Km)
EKi,j(Km)
EKi,j(Km)
EKi,j(Km)
EKi,j(Km)
Device A
EKi,j(Km)
Device B
EKi,j(Km)
EKi,j(Km) EKi,j(Km)
EKi,j(Km)

EKi,j(Km)
KMB is data structure w/multiple ciphers of same media
key under different device keys
9
Tree algorithm

Significantly more efficient

12 bytes per revocation


Single device or group of devices
Internet Research Task Force

Subset-Difference based Key Management for Secure Multicast
10
Binding

Media

CPRM/CPPM


Device

PVR time-shifting/pause live broadcast


Physical media playable on any compliant device, content
cannot be copied to other media unless authorized
Content can only be played on the device that recorded
it originally
User

xCP

All devices in a cluster can play all content recorded
within the cluster
11
xCP Model

Initialization


Binding


Content is cryptographically bound to this cluster, including
usage conditions
Compliance


Devices in a household form a “cluster” by agreeing on
common KMB, cluster ID (secret)
Only compliant devices can join the cluster
Renewability

As new KMBs are released, they are adopted by the cluster,
updating the local revocation list
Skip protocol
12
Cluster model
kmbserver
authorizer
KMB
authTable
Content
+usage rules
KMB
authTable
Content
+usage rules
client
13
Local Authorization Model
Step 1
Who’s there?
RSVP: myURL
14
Local Authorization Model
Step 2
I’m here!
I’m here!
15
Local Authorization Model
Step 3
Authorize me?
My Player ID is:
0xCAFEBABE and here
is a MAC computed with
your KMB
16
Local Authorization Model
Step 4
I verified the MAC,
I know the new
device is compliant
Must
remembe
r cluster
ID
There’s only 2 of
us so far, we can
have 1 more
Ok, you’re in.
Here’s the cluster ID,
encrypted just for you
17
Central Authorization Model
Step 1
Who’s there?
RSVP: myURL
18
Central Authorization Model
Step 2
I’m here!
19
Central Authorization Model
Step 3
Authorize me?
My Player ID is:
0xCAFEBABE and
here is a MAC
20
Central Authorization Model
Step 4
Please authorize player
0xCAFEBABE for
cluster 0xDEADBEEF
I need to talk to
the central
authorization
server
21
Central Authorization Model
Step 5
Player 0xCAFEBABE
authorized
Add a device to
cluster ID
0xDEADBEEF
Ok, you’re in.
Here’s the
cluster ID,
encrypted just
for you
Must
remember
cluster ID
22
Attack 1

Internet-delivered software clone


Five lines of Perl…
Solution: update MKB

Send MKB with content


Require periodic connection



Physical media, broadcast
Download updated MKB during reprovisioning
Cluster adopts new MKB
MKB revokes clone(s)
23
Attack 2

Block MKB update


Disconnect cluster
Solution: no more content


Since MKBs are delivered with content, blocking
MKBs means blocking content
No more content can be compromised
24
Attack 3

Roll back


(Re-)Introduce MKB that does not revoke clone
Solution: MKB merge


When new MKB is proposed, it is merged with
previous MKB
Revocation list is union of both MKBs
25
Attack 4

Bridge to “launder” content



Make a compliant device participate in multiple
clusters
Keep clusters separated
Solution: Authorization table



Peers are added to authTable
All share the same authTable
Content is bound to hash of authTable
26
A Scenario (I)

Movie distribution to a home network






Studio obtains KMB, device keys, chooses usage rules,
encrypts content
Content is distributed over existing channels (e.g. cable,
satellite, PPV), possibly with different usage rules
Additional protection may be layered, e.g. conditional access
(Alternatively, free-to-air content may be transmitted in the
clear, with broadcast flag set)
STB receives content, (re-)encrypts, binding to local cluster
Content downloaded over wireless network to minivan
storage for playback on road trip
27
A Scenario (II)

Export to legacy media






A device on the cluster supports both xCP and CPRM
(similarly DTCP, etc.)
Device checks usage rules, determines export is allowed
(e.g. copy once)
Content is re-encrypted, bound to media (i.e using MKB on
media, media id) with appropriate usage rules (e.g. copy no
more)
Content on media now plays on any CPRM compliant device,
not just those in the cluster
The different binding models are complementary
This chain of content protection solutions is the principle
behind CPSA.
28
A Scenario (III)

Forensics and renewability







A clone is detected (typically, Internet-distributed software)
Device keys used by the clone are determined using forensic
examination
A new KMB is released that revokes that set of keys
KMB is propagated to the cluster, e.g. new content is
protected by this new KMB
Any device on the cluster can propose a new KMB
KMB is merged with old one, devices revoked in either KMB
are left out
Other techniques (outside the scope of xCP)

Tracing traitors – identify leaks from bootleg content
29
Conclusion








Flexible model for end-to-end protection
Independent of transmission mechanism
Intermittently connected devices supported
No handshakes required
Fault tolerant, easy backup
Licensing for legal enforcement
Compatible with CPSA-compliant technologies
Balance between consumers’ and content
owner’s rights and expectations
30
Q&A
31
Thank you
Florian Pestoni
IBM Almaden Research Center
San Jose, CA
[email protected]
32
Where can I learn more about this?
IBM Submission to DVB
“DVB-CPT Call for Proposals for Content Protection & Copy Management”
ftp://dvbftp:[email protected]/dvb-cpt/DVB-CPT-716.pdf
IETF draft
“Subset-Difference based Key Management for Secure Multicast”
http://search.ietf.org/internet-drafts/draft-irtf-smug-subsetdifference-00.txt
Crypto 2001
“Revocation and Tracing Schemes for Stateless Receivers”
Dalit Naor, Moni Naor, Jeff Lotspiech
http://eprint.iacr.org/curr (Go to paper 2001/059)
Computer Magazine cover feature
“Broadcast encryption’s bright future”
Jeff Lotspiech, Stefan Nusser, Florian Pestoni
(to be published August 2002)
33