1 / 49

Privacy-preserving DRM

Privacy-preserving DRM. Radia Perlman; Intel Laboratories Charlie Kaufman; Microsoft Ray Perlner; NIST. The problem. Let Alice purchase content Without anyone knowing which content she purchased. Basic approach. Obtain (encrypted) content somehow from satellite TV

pascha
Télécharger la présentation

Privacy-preserving DRM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Privacy-preserving DRM Radia Perlman; Intel Laboratories Charlie Kaufman; Microsoft Ray Perlner; NIST

  2. The problem • Let Alice purchase content • Without anyone knowing which content she purchased

  3. Basic approach • Obtain (encrypted) content somehow • from satellite TV • from the Internet (through an anonymizer) • Purchase the content key

  4. With wrinkles • Additional authorization • Over 21 • Citizen of US • Citizen of any country other than Monaco • Differential costs (some things cost more than others) • Implications of content-provider provided sealed box at customer site

  5. Structure of talk • Two families of schemes • anonymous cash • blind decryption • Comparison of these schemes • Adding wrinkles with each scheme

  6. Encrypted content has metadata • The metadata might, for instance, contain the content key encrypted with the content provider’s public key • Presenting the metadata to the content provider allows it to return the content key

  7. Encrypted content: metadata {K}P content provider knows priv key, can decrypt {K}P and return K metadata: {K}P encrypted with K

  8. Encrypted content: metadata content ID content provider has table (ID, K) for all items, can look up K metadata: content ID encrypted with K

  9. Both schemes use concept of “blinding” • Alice wants Bob to sign or decrypt “x” with Bob’s private key • Alice creates functions (blind=B, unblind=U) that commute with Bob’s public/private key operations • Sends B(x) to Bob • Bob applies private key • Alice takes the result, applies U, to get signed or decrypted x

  10. Anonymous Cash • Chaum scheme for anonymous cash • Choose random number R, “blind it”, send it to bank to sign, then unblind it. A “token” is R, and the signature on R, say Rsig • Buying content • (non-anon) buy tokens, using real money • In an anonymous, encrypted conversation, present anonymous cash, ask for particular content key

  11. Anonymous Cash Scheme: Buying tokens Alice Content provider B(R1), B(R2), credit card debit credit card 2 units B(R1sig), B(R2sig) Unblind to obtain R1sig and R2sig

  12. Anonymous Cash Scheme: Purchasing content Alice Content provider R1, R1sig, content ID K Anonymizing cloud, encrypted conversation

  13. Scheme 2: Blind Decryption Alice Content provider B({K}P), “Alice” If request valid, do decryption and debit Alice’s account B(K) Note: conversation must be signed by Alice, plus have timestamp

  14. Comparisons • Per-item accounting • Possible in anonymous cash scheme • Not possible in blind decryption scheme • Efficiency (see next slide)

  15. Blind decryption more efficient • One conversation, vs anonymous cash • one to buy token • one by purchase content • One private key operation for content provider, vs in anonymous cash • blindly sign token • establish server-side encrypted/authenticated session • No need for anonymization cloud

  16. First wrinkle: variable charging Could be trivial with anon cash: present n tokens to buy something worth n units That would require n private key operations for the content provider (actually 2n because of originally signing them) Instead, can have different denomination tokens

  17. Variable charging: Anonymous cash • Content provider has different “denomination” public keys, say P1=“one”, P2=“10”, P3=“50” • When purchasing tokens, ask for denominations • I’m Radia • I’d like 4 ones: B(R1), B(R2), B(R3), B(R4) • And 2 tens: B(R5), B(R6) • And 3 fifties: B(R7), B(R8), B(R9) • Content provider applies P1 to first 4, P2 to next 2, P3 to next 3 • When (anonymously) purchasing content, provide all the necessary tokens

  18. Anonymous cash, different denominations • Might be suspicious to get anything more than a one, if all G-rated content was 1, and X-rated was more • Allow purchase of multiple things in the same transaction, so asking for a large denomination bill isn’t suspicious • Besides you could purchase with all one’s • content provider could discourage this paranoia by offering a discount for large denominations

  19. Anonymous Cash : Purchasing content that costs 12 units Alice Content provider (“one”, R1, R1sig, ), (“one”, R2, R2sig,),(“ten”, R3, R3sig, ),content ID K Anonymizing cloud, encrypted conversation

  20. Variable Charging: Blind Decryption • For an item costing 3 units, metadata would have 3 wrapped keys, K1, K2, K3, and content key is h(K1,K2,K3) • Could also have different denomination content provider public keys, just like anonymous cash • Metadata for something worth 12 units: • “one”: {K1}P1, “one”: {K2}P1, “ten”: {K3}P2 • Request to content provider: • “one”, B({K1}P1), “ten” B({K3}P2), “Alice” • Can request the keys at different times

  21. Variable Charging: Blind Decryption • If Alice is nervous buying something worth more than 10 units, metadata could give the choice of unwrapping 12 individual keys or a 10 and 2 ones. Alice’s choice • Could unwrap 12 ones, content key is XOR of all of those, or unwrap 2 ones and 1 ten, and content key is also XOR of those 3. • Content provider might provide discount for using larger denominations • Note: the component keys for this content can be purchased at different times

  22. Easy issue: Timing issue • When something is first broadcast, it might be likely that someone asking for content at that time is buying that content • So, provide the metadata well in advance

  23. New topic: Additional Authorization • Suppose you also have to prove “over 21” • Several scheme, with slightly different properties. • authorization secrets used as encryption keys • authorization secrets used as credentials • different content provider public keys

  24. Leaking of authorization secrets • Obvious concern • No matter how the secrets are used, what if they leak out? • No harder to leak these, or to protect these, than content keys • So we’re assuming some sort of DRM, whether hardware or software • Note: software DRM “can’t” be secure, but it is widely deployed

  25. Authorization secrets used as keys • Metadata would contain • ACL: “over 21”, “US” • {K}P (blind decryption), or content ID (anonymous cash) • Alice has already (nonanonymously) obtained and saved K21, and KUS. • Content key would be h(K, K21,KUS) • Somewhat bulky metadata with the OR of attributes, but everything is doable

  26. Auth secrets as credentials • Only works with anonymous cash scheme • Metadata would contain • ACL: “over 21”, “US” • content ID (anonymous cash) • Alice has already (nonanonymously) obtained K21, and KUS. • Anonymous, encrypted request • K21, KUS , content ID • Content provider checks ACL to make sure all necessary authorizations are proven, returns K

  27. Anonymous Cash Scheme: Purchasing content Alice Content provider cash, auth secrets, content ID K Anonymizing cloud, encrypted conversation

  28. Complex policies • Easy: ACL is part of metadata. Client figures out what is needed to satisfy it

  29. Comparison • Privacy issue • Could be there is only one Lithuanian with a PhD in Chinese literature with a plumbing license • auth secrets as credentials wouldn’t be very anonymous then.. • only relevant if ACL is complicated OR • Revocation of authorization secrets • In credentials scheme, easy to change secret periodically • With auth secrets as keys, you’d have to re-encrypt the data

  30. Third possibility: ACL-dependent content-provider keys

  31. ACL-dependent public keys Alice Content provider applies public key associated with that ACL “Alice”, “over 21 and not Lithuanian”, B({K}P) B(K) Note: conversation must be signed by Alice, plus have timestamp Content provider checks Alice profile to ensure she has attributes

  32. ACL-dependent public keys; cash • When asking for a token, specify which key (e.g., “US citizen”) • When purchasing ACL-dependent content, use the relevant cash

  33. Good, bad, and ugly of this variant • Good • No need for authorization secrets • No worry about authorization secrets getting shared • Revocation of Alice’s attributes very easy • Bad • Content provider knows ACL of the content Alice is asking for; could be very few possibilities • But could wrap content with more atomic attributes • Ugly (but not, with cute crypto) • Managing all these public keys

  34. Unique ACL • Could be only one piece of content that has the ACL “plumbing license AND alum of NYU” • So instead, you could have two keys in the metadata, one wrapped with “plumbing license” public key, and one wrapped with “alum of NYU” public key, and content key is XOR of the two of them

  35. How to do blindable, ACL-parameterized public keys • Use Diffie-Hellman keys • works with elliptic curves, but I’ll explain it with modular exponentiation, where it also works • All Alice knows for content provider’s key are the parameters “g” and “p” • Content provider just needs a single secret, let’s call it “S”

  36. Content provider encrypts an item • Choose a random number “y” • Calculate gy mod p • hash S with the ACL, e.g., h(S, “(plumbing license AND alum of NYU) OR member ACM”) = x • Calculate gxy mod p • Content key is h(gxy mod p)

  37. Alice wishes to purchase item • Metadata • ACL: plumbing license AND alum of NYU) OR member ACM • gy mod p • Unblinded: Send all that metadata to content provider, which derives “x” from the ACL, and sends back gxy mod p • Blinded: Choose z, calculate z-1, raise gy mod p to z, send ACL and gyz mod p

  38. ACL-dependent public keys Alice Content provider “Alice”, “plumbing license AND alum of NYU) OR member ACM”, gyz mod p gxyz mod p Note: conversation must be signed by Alice, plus have timestamp Content provider checks Alice profile to ensure she has attributes Alice raises to z-1 to obtain gxy mod p

  39. Note • Reminiscent of “identity based encryption” • But it’s not: nobody but content provider can know either public or private key

  40. IBE (Identity Based Encryption) • This works as well, where the content provider knows the domain secret, its “public key” is the domain parameter, and the ACL is the string

  41. RSA • This variant may work • Would be nice to have a proof • “Public key” is just modulus “n” • public exponent is h(ACL string) • “private key” is factorization of n

  42. Most subtle wrinkle: Sealed box • Common deployment scenario: sealed box at customer premises provided by content provider • Communication is between box and content provider • Customer can monitor communication, talk to box, intercept messages

  43. Sealed box provided by content provider content provider content provider’s box Alice’s computer

  44. Can Alice tell if box is cheating, and leaking privacy information? • Anonymous cash scheme • Absolutely not: communication between box and content provider must be encrypted with end-to-end key • Alice can’t tell anything about the conversation • Blind decryption • Looks sort of promising • Box says, in cleartext “timestamp, B(metadata)”

  45. But box can cheat • For instance, blinding function could be purposely weak, so that content provider can tell what content Alice is accessing • No way for Alice to be able to detect this is going on • But there’s hope

  46. Alice can add extra level of blinding content provider content provider’s box “Alice”, B2(B({K}P)) Alice’s computer “Alice”, B({K}P) B2(B(K)) B(K) choose 2nd blinding function B2 Note: Alice can’t cheat and get access to the content keys. Box can’t cheat and tell content provider what key is being decrypted

  47. But it doesn’t quite work • Problem: There needs to be end-to-end authentication between the box and the content provider, because content provider wants it to be “impossible” to get content keys out of boxes. • So Alice can’t modify messages between the box and the content provider.

  48. Solution: Alice can tell box to add her chosen 2nd level of blinding content provider content provider’s box “Alice”, B({K}P) “Alice”, B2(B({K}P)) Alice’s computer add blinding B2 “Alice”, B2(B({K}P)) B2(B(K)) B2(B(K)) choose 2nd blinding function B2 Note: Alice can’t cheat and get access to the content keys. Box can’t cheat and tell content provider what key is being decrypted

  49. Summary • Two basic schemes • anonymous cash • blind decryption • Wrinkles • variable costs • supporting arbitrarily complicated ACLs • allowing Alice to cooperate with box to preclude covert channel

More Related