1 / 21

Remote Revocation of Smart Cards in a Private DRM System

Remote Revocation of Smart Cards in a Private DRM System. Keith Frikken, Mikhail Atallah, Marina Bykova Purdue University February 2. Motivation. In a private DRM system, a user’s identity or smartcard is not linked to a transaction Problem: What if a smartcard is cracked?

cody
Download Presentation

Remote Revocation of Smart Cards in a Private DRM System

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. Remote Revocation of Smart Cards in a Private DRM System Keith Frikken, Mikhail Atallah, Marina Bykova Purdue University February 2 AISW 2005

  2. Motivation • In a private DRM system, a user’s identity or smartcard is not linked to a transaction • Problem: What if a smartcard is cracked? • Smartcards are not easy to crack, but it is possible [Anderson and Kuhn, 1996][Anderson and Kuhn, 1997] • Adversary can distribute content or key information • Content distributor must plan for such occurrences • If content distributor learns that a key is compromised, he must stop using effected keys AISW 2005

  3. Problem Description • S is a server that distributes content • Clients C0,…,Cn request content from S • Each client has a smartcard • Goal: A content distribution system with the following properties: • Protected: Only clients with smartcards can access data • Private: S should not be able to determine which smartcard is accessing data AISW 2005

  4. Properties (cont.) • Revocable: If S finds that a smartcard has been cracked, it should be able revoke the key • Non-interactive: S and the client do not engage in a protocol • Efficient: In communication and computation • Forward and Backward Secure • Newly issued smartcards cannot read previous messages • Revoked smartcards cannot read future messages AISW 2005

  5. Related Work • Broadcast Encryption: Allows a distribution center to securely broadcast data to a dynamically changing set of users • [Berkovitz, 1991] introduced broadcast encryption • [Fiat and Naor, 1994] • Formal study • Each user stores O(k log k log n) keys • Center broadcast O(k2 log2k log n) messages where k is revocation threshold • Multicast Security: requires stateful receivers • [Wong, Gouda, and Lam, 1999] • [Wallner, Harder, and Agee, 1999] • [Canetti, Garay, Itkis, Micciancio, Naor, and Pinkas, 1999] • [Canetti, Malkhi, and Nissim, 1999] AISW 2005

  6. Related Work(2) • Tree-based approach • [Halevy and Shamir, 2002] • Combinatorial Approaches • [Kumar, Rejagopalan, and Sahai, 1999] • [Garay, Staddon, and Wool,2000] • [McGrew and Sherman, 1998] • Other Approaches • [Attrapadung, Kobara, and Imai, 2003] AISW 2005

  7. Cryptographic Primitives • Commutative One-way functions (i.e., G(H(x))=H(G(x)) • For non-collusion resilience: Use RSA with public modulus and encryption keys • For collusion-resilience: No known (at least to us) scheme that is commutative and resilient to collusion AISW 2005

  8. Notations • Use Hj(x) to represent H applied j times to the value x • We use Ki,j to represent Hi(Gj(x)) • Given Ki,j, G, and H one can generate Kx,y only when (i,j) dominates (x,y) (i.e., i≤x and j≤y) AISW 2005

  9. Preliminary Protocol(1) • Server Initialization • C is the set of all cards Co,…,Cn • R is the set of revoked smartcards • H and G are commutative one-way functions • x is a random value • K is the set of all keys, initialized to {Hn(Gn(x))} • Smartcard Initialization • Card Ci is given Ki,n-i=Hi(Gn-i(x)) • Sending a message • Encrypt(M,k) for some random key k • For each key Ki,j in K, Encrypt(k,Ki,j) AISW 2005

  10. Preliminary Protocol(2) • Revoking a key • To revoke key Ki,j: • Find all keys Kx,y in K where (i,j) dominates (x,y) • Replace Kx,y with Ki-1,y and Kx,j-1 • Example • If there are 11 users, and K={K10,10} and card C6 is to be revoked (i.e., key K6,4) • New key set is {K5,10,K10,3} AISW 2005

  11. Example AISW 2005

  12. Example AISW 2005

  13. Example AISW 2005

  14. Efficiency • Server initialization: requires O(nlogn) evaluations of commutative one-way function • Smartcard initialization: O(n) commutative one-way functions • Sending a message after f revocations: Server must send out at most f+1 encryptions • Smartcard work after a revocation: O(n) commutative one-way functions AISW 2005

  15. Extensions(1) • Grouping: Partition cards into groups • Offloading smartcard work • Reducing Server’s load • Filtering Keys • Adding new smartcards • “Undo”ing a revocation AISW 2005

  16. Extensions(2) • Higher-dimension scheme • Have d commutative one-way functions: H1,H2,…,Hd • For 3 dimensions smartcard needs to perform O(sqrt(n)) one-way functions • For d dimensions smartcard needs to perform O(dn1/d-1) one-way functions • Also, |K|=O(df) AISW 2005

  17. Experimental Results AISW 2005

  18. Extensions(3) • Hypercube scheme • Given a d-dimensional hypercube, the keys would be values Ki1,…,id where i1+…+id=d/2. • Number of keys is ~ 2d(sqrt(2/d)) • Smartcard only needs to perform O(log n) commutative hash function operations AISW 2005

  19. Experimental Results AISW 2005

  20. Open Problems • In the higher-dimensional schemes for d dimensions, is there a tight upper bound for the number of keys after f failures? What is the expected number? • In the hypercube scheme for d dimensions, is there a tight upper bound for the number of keys after f failures? What is the expected number? • Is there a way to achieve similar results without requiring the smartcard to perform any modular exponentiations? AISW 2005

  21. Acknowledgements • Gov’t • NSF5, ONR, AFRL • Industry • Intel, Motorola, HP + the corporate sponsors of CERIAS • Foundation • Lilly Endowment • Purdue • CERIAS, Discovery Park AISW 2005

More Related