Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
... but DRM is Evil!?
http://www.flickr.com/photos/gregoryh/162461886/
Tuesday, April 14, 2009
Outline
• DRM vs “Traditional” Security
• Determining Authorization
• Enforcing Authorization
• Peer-to-Peer Protocols
• Client Protection
Tuesday, April 14, 2009
Traditional security exists to protect you...
Tuesday, April 14, 2009
... DRM exists to protect content from you
http://msdn.microsoft.com/en-us/library/aa376846(VS.85).aspx
Tuesday, April 14, 2009
(and everyone else)
http://msdn.microsoft.com/en-us/library/aa376846(VS.85).aspx
Tuesday, April 14, 2009
Transport-Layer Security
http://www.flickr.com/photos/morgandavis/3227529185/
Tuesday, April 14, 2009
Transport-Layer Security
http://www.flickr.com/photos/morgandavis/3227529185/
(A.K.A SSL)
Tuesday, April 14, 2009
Transport-Layer Security
• Guarantees*
• Confidentiality
• Integrity
• Authenticity
* If Used Correctly
Tuesday, April 14, 2009
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...
Tuesday, April 14, 2009
Transport-Layer Security
• Guarantees*
• Confidentiality
• Integrity
• Authenticity
So, what else do we need?
Tuesday, April 14, 2009
DRM Restrictions
• Subscriptions
• Time
• Location
• ...
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
Authentication
username
ClientServer
nonce
E(nonce, password)
Where:
nonce = randomly-generated, single-use dataE(x, y) = "Encrypt 'x' using key 'y' "
Challenge-Response:
Tuesday, April 14, 2009
Authentication
Setup TLS Session
ClientServer
username, password
Encrypted Tunnel
With TLS:
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
Aside: Don’t re-invent the wheel!
http://www.flickr.com/photos/vrogy/514733529/
Tuesday, April 14, 2009
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)
Tuesday, April 14, 2009
Geo-location
http://www.flickr.com/photos/caveman_92223/3185534518/
Tuesday, April 14, 2009
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?)
Tuesday, April 14, 2009
Enforcing Authorization
• If the content server is the authorization server, this is easy
• If they’re separate, this is a little more interesting
Tuesday, April 14, 2009
Separating Authorization and Delivery
• Why?
• Modular Design :-)
• Need more delivery servers than authorization servers
• Delivery servers might not be yours (CDN)
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
Tokens
MAC(K, M)
M
Stream ID Client IP Valid-Until
K: shared-secret between Authorization and Content serversMAC: Message Authentication Code
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
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)
Tuesday, April 14, 2009
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”
Tuesday, April 14, 2009
Broadcast Encryption
• Why?
• More efficient
• Required in “Multicast” scenarios (e.g. IP Multicast, Radio, Blu-Ray Discs, ...)
Tuesday, April 14, 2009
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...)
Tuesday, April 14, 2009
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...)
Tuesday, April 14, 2009
Broadcast Encryption -Key Refresh
• Idea: encrypt new content keys with previous content keys?
• Efficient - can “broadcast” the key updates
Tuesday, April 14, 2009
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...
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
Subset Difference Tree
• 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
Tuesday, April 14, 2009
Subset Difference Tree
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...
Tuesday, April 14, 2009
Subset Difference Tree
• 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
Tuesday, April 14, 2009
Subset Difference Tree
• 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 cannot be used (known tounauthorized receiver)
Key will be used
Tuesday, April 14, 2009
Subset Difference Tree
• 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 cannot be used (known tounauthorized receiver)
Key will be used
Tuesday, April 14, 2009
Subset Difference Tree
• 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?
Tuesday, April 14, 2009
Subset Difference Tree
• 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)
Tuesday, April 14, 2009
Peer-to-Peer
http://www.flickr.com/photos/caddysnaps/359910335/
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
Collusion?
• What if multiple peers cooperate to break your restrictions?
Tuesday, April 14, 2009
Client Protection
http://neftriplecrunch.files.wordpress.com/2008/12/sisyphus.jpg
Tuesday, April 14, 2009
Client Protection
• Integrity Verification
• Code Obfuscation
• Key Protection
Tuesday, April 14, 2009
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...
Tuesday, April 14, 2009
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...
Tuesday, April 14, 2009
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)
Tuesday, April 14, 2009
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”)
Tuesday, April 14, 2009
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...
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
Code Obfuscation
• Optimization and Obfuscation often go hand-in-hand:
• Inline Functions
• Unrolled Loops
• “Stripped” Binaries
• (opaque predicates are an exception)
Tuesday, April 14, 2009
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
Tuesday, April 14, 2009
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/
Tuesday, April 14, 2009
More?
• Client Protection
• http://www.secdev.org/conf/skype_BHEU06.handout.pdf - a few years old, but very interesting...
• Prof. Halderman
Tuesday, April 14, 2009
Questions?Feel free to contact me:
Tuesday, April 14, 2009