streaming media content protectionstreaming media content protection adam goodman [email protected]...

Streaming Media Content Protection

Adam [email protected]

April 8, 2009

Tuesday, April 14, 2009

mailto:[email protected]


Streaming Media DRMAdam Goodman

[email protected] 8, 2009




... but DRM is Evil!?

http://www.flickr.com/photos/gregoryh/162461886/




Outline

• DRM vs “Traditional” Security

• Determining Authorization

• Enforcing Authorization

• Peer-to-Peer Protocols

• Client Protection


Traditional security exists to protect you...


... DRM exists to protect content from you

http://msdn.microsoft.com/en-us/library/aa376846(VS.85).aspx




(and everyone else)





Transport-Layer Security

http://www.flickr.com/photos/morgandavis/3227529185/






(A.K.A SSL)





• Guarantees*

• Confidentiality

• Integrity

• Authenticity

* If Used Correctly


Aside: SSL/TLS Caveats

• Confidentiality, Integrity are “easy”

• Authenticity ... not so much

• Relies on a “chain of trust”

• (better in a closed system)

• Also, users must pay attention...



• Guarantees*

• Confidentiality

• Integrity

• Authenticity

So, what else do we need?


DRM Restrictions

• Subscriptions

• Time

• Location

• ...


Determining Authorization

Authorization Server

User Database

Policy

IP Geolocation

Database

"I'm user X,and here's proof"

"user X has subscribed to channel 1 "

"channel 1 can be watched onlyfrom the US, with a subscription"

"ip '1.2.3.4' isin the US"

Clientip: 1.2.3.4

Result: Client can watch channel 1


Authentication

username

ClientServer

nonce

E(nonce, password)

Where:

nonce = randomly-generated, single-use dataE(x, y) = "Encrypt 'x' using key 'y' "

Challenge-Response:


Authentication

Setup TLS Session

ClientServer

username, password

Encrypted Tunnel

With TLS:


Which One’s Better?

TLS Challenge-Response

+ Easy+ Protects the entire

session- Performance- Gives the actual

password to the server

+ Performance+ Places less trust in the

server- Requires thought- Subsequent messages

are not (inherently) protected


Performance

• RSA-2048: ~13 KB/sec

• AES-256: ~60,000 KB/sec

• AES-256 is over 4,500x faster than RSA-2048!

OpenSSL 0.9.7l 28 Sep 2006built on: Thu Jul 17 22:00:44 PDT 2008options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: cc -arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -arch ppc -arch ppc64 -arch i386 -arch x86_64 -pipe -DOPENSSL_NO_IDEA -DFAR=available timing options: TIMEB USE_TOD HZ=100 [sysconf value]timing function used: aes-128 cbc 78397.82k 82842.53k 75812.81k 83514.80k 84863.44kaes-256 cbc 61200.85k 62524.43k 62176.15k 62542.61k 62809.65k sign verify sign/s verify/srsa 1024 bits 0.003432s 0.000148s 291.4 6768.2rsa 2048 bits 0.019858s 0.000508s 50.4 1969.6


Aside: Don’t re-invent the wheel!

http://www.flickr.com/photos/vrogy/514733529/




Aside: Don’t re-invent the wheel!

• See, for example:

• MS-CHAPv1 (http://www.schneier.com/pptp.html)

• WEP(http://www.crypto.com/papers/others/rc4_ksaproc.pdf)


http://www.schneier.com/pptp.html

http://www.schneier.com/pptp.html

http://www.crypto.com/papers/others/rc4_ksaproc.pdf




Geo-location

http://www.flickr.com/photos/caveman_92223/3185534518/




IP Geo-location• Relied upon by all (Hulu, BBC, Zattoo, ...)

• Determined from:

• Internet Registries (e.g. ARIN, RIPE)

• ISPs

• Public Routing Information

• Easily circumvented by proxies / VPNs

• (how to combat?)


Enforcing Authorization

• If the content server is the authorization server, this is easy

• If they’re separate, this is a little more interesting


Separating Authorization and Delivery

• Why?

• Modular Design :-)

• Need more delivery servers than authorization servers

• Delivery servers might not be yours (CDN)


Separating Authorization and Delivery

• How?

• “Tickets” / “Tokens” (Similar to Kerberos)

• Token Goals:

• Provide proof of authorization

• Ensure that any information used to determine authorization has not changed


Tokens

MAC(K, M)

M

Stream ID Client IP Valid-Until

K: shared-secret between Authorization and Content serversMAC: Message Authentication Code


Message Authentication Code• E(x, k) does not necessarily guarantee

integrity

• e.g. binary protocol with no checksum

• MAC - similar to a digital signature, but with symmetric keys

• Anyone who can verify the MAC can tamper with it

• But otherwise, guarantees are similar


HMAC

• Probably, the most popular MAC function:HMAC(K, m) = H[(K XOR opad) | H[(K XOR ipad) | m]]

H: hash function (e.g. SHA-1)K: keym: message|: concatenation

opad, ipad: “magic numbers”, defined by the creators (e.g. to be particularly resistant to cryptanalysis)


Content Encryption

• Re-encrypt content for each client

• e.g. establish a TLS connection for each client

• High overhead

• Encrypt content only once, but control key distribution carefully

• “Broadcast Encryption”


Broadcast Encryption

• Why?

• More efficient

• Required in “Multicast” scenarios (e.g. IP Multicast, Radio, Blu-Ray Discs, ...)


Broadcast Encryption - Key Distribution

• Send the content key confidentially to each authorized client

• e.g. over TLS

• (Better: establish a long-term session key that doesn’t require holding open a TCP connection...)


Broadcast Encryption - Key Refresh

• Revocation: don’t want to use the same content key for too long

• Clients may only be authorized for a limited period of time...

• Clients could “share” key with unauthorized friends (still a risk, but it’s harder to hit a moving target...)


Broadcast Encryption -Key Refresh

• Idea: encrypt new content keys with previous content keys?

• Efficient - can “broadcast” the key updates


Broadcast Encryption -Key Refresh

• Bad Idea: encrypt new content keys with previous content keys.

• Any client that once had authorization can potentially decrypt all future content

• Okay Idea: distribute new content keys individually, as before...


Subset Difference Tree

• Construct a complete binary tree with at least n leaves (for n receivers)

• Each leaf node represents a receiver (labeled r0-r7)

000 001

00

010 011

01

0

100 101

10

110 111

11

1

r0 r1 r2 r3 r4 r5 r6 r7



• Provide each receiver all the keys on the path from it to the root node

• Receiver r2 gets all of the highlighted keys

000 001

00

010 011

01

0

100 101

10

110 111

11

1

r0 r1 r2 r3 r4 r5 r6 r7



000 001

00

010 011

01

0

100 101

10

110 111

11

1

r0 r1 r2 r3 r4 r5 r6 r7

• Key Distribution: Find the minimum set of keys such that all authorized receivers have at least one key in the set, and all unauthorized receivers have none...



• To send a content key to all receivers: Encrypt it once, with the key representing the “root node” of the tree

000 001

00

010 011

01

0

100 101

10

110 111

11

1

r0 r1 r2 r3 r4 r5 r6 r7

Key cannot be used (known tounauthorized receiver)

Key will be used



• To send a content key to all receivers except r2: Send 3 encrypted versions of it (using keys 1, 00, 011)

000 001

00

010 011

01

0

100 101

10

110 111

11

1

r0 r1 r2 r3 r4 r5 r6 r7


Key will be used



• Generally, minimal set of valid keys will consist of the root node of each subtree that is adjacent to - but not overlapping - the path defined by the ‘unusable’ keys

000 001

00

010 011

01

0

100 101

10

110 111

11

1

r0 r1 r2 r3 r4 r5 r6 r7


Key will be used



• Principle is used by AACS (Blu-Ray, HD-DVD) for key revocation, though the implementation is different

• Could be more difficult to adapt this to a highly-dynamic system (e.g. streaming content)

• High churn could negate its advantages

• Periodic reconstruction?



• Original Principle: http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf

• AACS Specification: http://www.aacsla.com/specifications/specs091/AACS_Spec_Common_0.91.pdf (Chapter 3)


http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf




http://www.aacsla.com/specifications/specs091/AACS_Spec_Common_0.91.pdf




Peer-to-Peer

http://www.flickr.com/photos/caddysnaps/359910335/




Overview

Streaming Server

Client ClientClient Client ...

Streaming Server

Client ClientClient Client ...

Unicast

IP MulticastTuesday, April 14, 2009

Overview

Client

Client Client

Client

Client

Streaming Server

Client Client

...

Peer-to-Peer


P2P Content Protection

• Just like IP Multicast?

• Send the keys separately (or broadcast multiple copies through a specialized mechanism)

• Or...

• Distribute the keys as part of the P2P protocol


Tokens, Revisited

• If peers are passing out content keys, they need to verify authorization

• Using a MAC in the token is insufficient!

• Use “digital signatures” (asymmetric crypto) instead

• Peers can verify signatures, but only the authorization server may create them


Collusion?

• What if multiple peers cooperate to break your restrictions?


Client Protection

http://neftriplecrunch.files.wordpress.com/2008/12/sisyphus.jpg




Client Protection

• Integrity Verification

• Code Obfuscation

• Key Protection


Integrity Verification

• Simple: client hashes itself on startup, checks the result against a stored value

• Easily defeated

• Slightly less bad: client hashes itself on startup, sends the result to a server

• Can just ‘replay’ the good value...


Integrity Verification

• Better: Server provides some parameters (a “challenge”) which client uses in a special hashing algorithm; server verifies client response

• Significantly better; no chance of ‘replay’ attack, or removing the check entirely

• Hashing in-memory or on-disk

• Hashing could be redirected...


Integrity Verification• Better Still: Continuous, dynamic

checksums (Skype, ...)

• Debugger detection

• ‘Soft’ breakpoints require injecting instructions into your code; dynamic check-summing can detect this

• ‘Hard’ breakpoints are in the CPU itself, so can’t be detected (but much harder to use)


Code Obfuscation

• Basic premise: make your code really hard to understand, but functionally equivalent

• (I love this paper title: “Breaking Abstractions and Unstructuring Data Structures”)


Code Obfuscation

• Example: Opaque Predicates

• Insert branches throughout your code that depend on deterministic values (predicates) that are difficult to find from code analysis

• Ideally, spread calculation of these “predicates” over both space and time...


Code Obfuscation

• Example: Opaque Predicates

Skype protectionsSkype seen from the network

Advanced/diverted Skype functions

Binary packingCode integrity checksAnti debugging technicsCode obfuscation

In C, this means

Determined conditional jumps

. . .i f ( s i n (a ) == 42 ) {

do dummy stuff ( ) ;}go on ( ) ;. . .

Philippe BIONDI, Fabrice DESCLAUX Silver Needle in the Skype 36/98from http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf


Code Obfuscation

• Optimization and Obfuscation often go hand-in-hand:

• Inline Functions

• Unrolled Loops

• “Stripped” Binaries

• (opaque predicates are an exception)


Key Protection

• All keys must be stored somewhere, somehow

• Apply some obfuscation to their storage (even in memory) except at the exact moments when they’re needed


More?• Nate Lawson - one of the architects of Blu-

Ray DRM:

• http://root.org/talks/RSA2008_DesigningAttackingDRM.pdf

• http://root.org/ and http://rdist.root.org/

• If you dislike DRM:

• http://www.eff.org

• http://www.freedom-to-tinker.com/


http://root.org/talks/RSA2008_DesigningAttackingDRM.pdf




http://rdist.root.org




http://www.eff.org

http://www.eff.org

http://www.freedom-to-tinker.com

http://www.freedom-to-tinker.com

More?

• Client Protection

• http://www.secdev.org/conf/skype_BHEU06.handout.pdf - a few years old, but very interesting...

• Prof. Halderman


http://www.secdev.org/conf/skype_BHEU06.handout.pdf




Questions?Feel free to contact me:

[email protected]




streaming media content protectionstreaming media content protection adam goodman [email protected]...

Documents