1 / 19

563.13.2 Client Puzzles

563.13.2 Client Puzzles. Daniel Rebolledo, Ellick Chan, Sonia Jahid, Evgeni Peryshkin University of Illinois Fall 2007. Definition. “[A client puzzle is a] quickly computable cryptographic problem.” A. Juels, J. Brainard

kali
Download Presentation

563.13.2 Client Puzzles

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. 563.13.2Client Puzzles Daniel Rebolledo, Ellick Chan, Sonia Jahid, Evgeni Peryshkin University of Illinois Fall 2007

  2. Definition “[A client puzzle is a] quickly computable cryptographic problem.” A. Juels, J. Brainard “Client Puzzle Protocol (CPP) is a computer algorithm for use in Internet communication, whose goal is to make abuse of server resources infeasible.” Wikipedia Juels Brainard 1999, Wikipedia

  3. Threat model Loss of availability to legitimate clients through stateful server-side resource depletion by malicious clients. Examples: • SYN Floods • Server-side expensive operations (e.g. cryptographic computations, database queries, etc.) • Connection table flooding Counter-examples: • DNS Resolution (stateless) • Bandwidth flooding

  4. Basic Idea of Client Puzzles Pricing: attach a small cost to protocol initiation (processor time, memory, …) The cost is much higher for attackers than for a legitimate client Attacks are rate limited by puzzle cost Resource request Puzzle parameters Server Client Puzzle solution Resource Juels Brainard 1999

  5. Design Considerations • The puzzles should not introduce any new DoS vulnerabilities. • Creating a puzzle and/or verifying the solution is inexpensive for the server • Server should be stateless • The difficulty of the puzzle should be easy to adjust • Replay resistant • Precomputing solutions is difficult • Sharing the solution has minimal impact • No central point of failure • Does not consume server resources • Does not consume excessive network resources • Is fair to clients with different capabilities (slow machines, mobile devices) • Compatibility with existing clients Aura Nikander Leiwo 2000Koike 2002

  6. Puzzle Generation g, h: non-invertible hash functions. The server chooses a number x = g (secret, time, …), its hash y=h(x) and a level of difficulty k. It sends x[k+1,l] and y and asks the client to find x[1,k] by brute force. x[1,k] x[k+1,l] x y= h(x) y y Juels Brainard 1999

  7. Client Puzzle Protocols Puzzle? Server Client No Puzzle Initiate protocol Server under normal load Puzzle? Yes, Puzzle Server Client Puzzle solution Initiate protocol Server under attack Juels Brainard 1999

  8. Case study: Killbot Requires the client to solve a graphical puzzle (CAPTCHA) to access the service. The server keeps track of successful and failed authentication attempts and allows access using that information. When the server is at capacity, it drops new authentication requests.

  9. Killbot Simulation Results Kandula et al 2005

  10. Killbot Simulation Results Kandula et al 2005

  11. Vulnerabilities of Existing Systems • The puzzles should not introduce any new DoS vulnerabilities. • The difficulty of the puzzle should be easy to adjust • Replay resistant • Precomputing solutions is difficult • Sharing the solution has minimal impact • No central point of failure • Does not consume server resources • Does not consume network resources • Is fair to clients with different resources

  12. Design goals No central point of failure Distributed puzzle protocol Does not consume server resources The server does not generate the puzzle and doesn’t track which puzzle belongs to whom Does not reveal entropy information We avoid leaking information about the random number generation for other protocols

  13. Unilateral contract Definition “A one-sided agreement whereby you promise to do something in return for performance of a condition (not a promise)” How does this apply to client puzzles? Service = access to the internet service Condition = showing proof of (sufficient) work Why should puzzles work this way? • Server resources are not consumed • The server doesn’t reveal RNG entropy information Wordnet

  14. Proposed Architecture Logical Time Server Router Client 14 14

  15. Proposed Architecture Client Routers Server T0 T0 +C Check T1-T0 < epsilon Syn, Puzzle and solution T1 Syn Ack Time …

  16. Research Challenges • Formal analysis of the protocols/exclusion/auction, etc • Security (availability) analysis • Impact on web crawlers, proxies and thin clients (e.g. cell phones) • Parameter tuning: logical timestamp frequency, tolerance to clock skews • Securing the distributed logical timestamp protocol • Adaptive presentation: clients get more service if they solve more complex puzzles • Application to stateful packet filtering firewalls

  17. Conclusion • Attackers have evolved to semantic-level attacks to behave more like typical users • Client puzzles can help to defend against denial of service attacks which involve server resources • Our proposed approach redistributes puzzle parameters to help eliminate single points of attack

  18. References • Ari Juels and John Brainard, Client Puzzles: A Cryptographic Countermeasure Against Connection Depletion Attacks. In S. Kent, editor, Proceedings of NDSS '99 (Networks and Distributed Security Systems), pages 151-165, 1999. • J. Alex Halderman and Brent Waters, Harvesting Verifiable Challenges from Oblivious Online Sources. In Proceedings of the 14th ACM Conference on Computer and Communications Security (CCS 2007) • X.Wang and M. Reiter. Defending against denial-of-service attacks with puzzle auctions. In Proc. IEEE Security and Privacy '03, pages 78-92, 2003. • Jussipekka Leiwo, Pekka Nikander, and Tuomas Aura. Towards network denial of service resistant protocols. In Proceedings of the 15th International Information Security Conference (IFIP/SEC 2000), Beijing, China, August 2000. Kluwer. • W. Feng, The case for TCP/IP puzzles. Proc. SIGCOMM Workshop on Future Directions in Network Architecture, pp. 332-327, 2003

  19. References • W. Feng, E. Kaiser, W. Feng, A. Luu. The design and implementation of network puzzles. Proc. INFOCOM, 2005 • V. Gligor, Guaranteeing access in spite of service-flooding attacks, Proc. Security Protocols Workshop, 2003 • DOS-Resistant Authentication with Client Puzzles. Toumas Aura, Pekka Nikander, and Jussipekka Leiwo. Proceedings of the 8th International Workshop on Security, 2000 • Using Client Puzzles to Protect TLS. Drew Dean, Adam Stubblefield. Usenix, 2001 • Moderately Hard, Memory-Bound Functions. Martin Abadi, Mike Burrows, Mark Manasse and Ted Wobber. ACM Transactions on Internet Technology, 2005 • Client Puzzles as a Defense Against Network Denial of Service. Deanna Koike

More Related