563 3 3 Do S Defense by Proof

563. 3. 3 Do. S Defense by Proof Computer Security II CS 463/ECE 424 University of Illinois

Proof Concept • Require some proof that service for a client is desired or some evidence that would make it easier to eliminated unwanted requests. • Authentication is the most obvious type of proof, but it has its limitations. • A variety of practical alternatives and extensions have been proposed. 2

Proof Strategies Cookies verify that a request from a client comes from a given address and delay the creation of state on the server until there is a level of commitment from the client. Capabilities provide a potentially practical way to let servers inform the network that traffic is wanted without a global authentication system. Proof-of-work based on puzzles or bandwidth cause clients to prove they are willing to work to obtain service. 3

Cookies

Idea of a Do. S Defense Cookie • Assure, to a reasonable degree of certainty, that a client can receive a packet at its claimed source address • This is done by sending a hard-to-guess value, the cookie, to the client in response to its initial request. • This makes spoofing of source addresses difficult. • The idea is used in many contexts: TCP, IKEv 2. 5

SYN Cookies Usual 3 -way handshake Handshake with cookie SYN CK +A SYN Include Cookie in ACK AC K <D ata 5 bits [Bernstein. S 96] K a. F w> Time Counter AC <D at Flo Client Calculate and CK Issue Cookie N+A SY Server MSS 3 bits Client low > Verify Cookie and Allocate Server State Server md 5(caddr, cport, saddr, sport, time counter) 24 bits 6

SYN Cookies are Easy to Deploy Backwards compatible Transparent to clients Conform to RFC requirements for TCP No performance impact until SYNs become a problem • Good performance under attack • Limited drawbacks: hangs if ACK is lost, cannot use large window sizes • • 7

IKE Do. S Vulnerability • Basic premise: calculating a Diffie-Hellman (DH) shared secret is computationally expensive • Attacker initiates a large number of IPSec connections and passes garbage as the DH Public Key • Same situation as a SYN flood, except the attacker is exhausting CPU cycles rather • IKEv 2 RFC adds optional initial cookie exchange to its base protocol. 8

Limits of Cookies • Exhaustion: TCP SYN Cookies offer 24 bits of protection, Photuris Cookies offer 128 bits • Stale cookies: Once issued, a cookie is valid for some period of time (each 64 s a new one under Linux) • Eves dropping: Cookies rely on the unsecured confidentiality of the Internet path between client and server. 9

Capabilities

Basic Idea of Capabilities • Openness of Internet: any node / app can send anything to another point in the network. – New Internet apps can be introduced without changing the routing – Lower cost • Capability: tokens, representing one-time temporary leases or capabilities to send – Authenticates that the packet is desired by the destination. 11

TVA Alice Pre. Capability (Pi)= RTS hash(src. IP, dest. IP, time, secret) Pr e 1 • RTS rate limited – 1 -5% of bandwidth Pre 1, Pre 2 • Pi Queue at Router • Fair queued on Pi CNN [Yang. WA 05] 12

TVA Alice Capability 1 = timestamp || Hash (N, T, Pre. Cap 1) • Server offers: N bytes, T seconds • Stateless server – Does not store N, T – Input link C, minimum sending rate N/T – C/(N/T) records Cap 1, Cap 2 C AP ap 1, C ap 2 CAP • Router state (Per destination Q) CAP Capability 2 = timestamp || Hash (N, T, Pre. Cap 2) Cap 1, Cap 2 CNN 13

Limits of TVA • Legacy traffic suffers highly • Requires updating edge routers (pre-caps, capability, per flow queuing) • Changed network stack with capability packets • Assumes a certain knowledge of path capacities on server side to assign capabilities to flows 14

Proof of Computing Power

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 Client Puzzle solution Server Resource 16

Hashcash Puzzles 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 bits x[k+1, l] and y – asks the client to find bits x[1, k] by brute force. x[1, k] x[k+1, l] x y = h(x) y y 17

Proof of Bandwidth

Bandwidth as a Resource • Valid clients have more bandwidth available to them than attackers; attackers are “maxed out” on bandwidth during attack but valid clients have reserves. • If valid clients increase their communications with a server they will tend to overwhelm attackers. • Realizations of this strategy: Selective Verification and Bandwidth Auctions 19

Attack Profile R A A loads this channel with bad packets S requires low b/w channel with high processing cost at R S 20

Selective Verification A R S [Gunter. KTV 04] 21

Selective Verification A gets reduced channel A R R makes channels lossy Tradeoff: bandwidth vs. processing S S adds redundancy 22

Bandwidth Auctions • Server keeps a record of bytes sent by potential clients • Service is provided to clients who have sent the most bytes • Feedback mechanism can be implemented by using HTTP posts with an indication of how many bytes might be required to get service [Walfish. VBKS 06] 23

Adaptive Selective Verification • Client starts with sending a REQ • Doubles REQ rates after not getting service (i. e. ACK) in a round (T seconds) for up to J rounds • Server performs probabilistic random sampling of requests • Theoretically and experimentally shown to be efficient in terms of bandwidth consumption • Requires limited state on the server Khanna. VFKG 08] 24

Proof of Humanity Reverse Turing Tests (RTTs)

Challenges with Proof of Computation and Bandwidth • Limited deployment of protocols • Intrinsic differences between the capabilities of hosts • High availability of computational resources on a botnet • Diversified origins in botnet allows bots to look normal • Strategy: prove a human is responsible for each request 26

RTTs and CAPTCHAs • Turing Test: interview a principal and decide if the principal is a computer • Reverse Turing Test (RTT): find out if they are a human • Naor proposed RTTs as a defense against Do. S • Idea used for Alta Vista in 1997 • Gained recent popularity through use by Yahoo! Under the rubric of Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) [Naor 96] [Ahn. BL 04] 27

Types of CAPTCHAs • Text based – Gimpy, ez-gimpy – Gimpy-r, Google CAPTCHA – Simard’s HIP (MSN) • Graphic based – Bongo – Pix • Audio based 28

Text Based CAPTCHAs • Gimpy, ez-gimpy – Pick a word or words from a small dictionary – Distort them and add noise and background • Gimpy-r, Google’s CAPTCHA – Pick random letters – Distort them, add noise and background • Simard’s HIP – Pick random letters and numbers – Distort them and add arcs 29

Text Based CAPTCHAs 30

Graphic Based CAPTCHAs • Bongo – Display two series of blocks – User must find the characteristic that sets the two series apart – User is asked to determine which series each of four single blocks belongs to Difference? thick vs. thin lines 31

Graphic Based CAPTCHAs • PIX – Create a large database of labeled images – Pick a concrete object – Pick four images of the object from the images database – Distort the images – Ask the user to pick the object for a list of words 32

Graphic Based CAPTCHAs Dog Pool 33

Audio Based CAPTCHAs • Pick a word or a sequence of numbers at random • Render them into an audio clip using a TTS software • Distort the audio clip • Ask the user to identify and type the word or numbers 34

Breaking CAPTCHAs • Most text based CAPTCHAs have been broken by software – OCR – Segmentation • Other CAPTCHAs were broken by streaming the tests for unsuspecting users to solve. 35

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. [Kandula. KJB 05] 36

Reading • [Bernstein. S 96] SYN Cookies, D. J. Bernstein and Eric Schenk. http: //cr. yp. to/syncookies. html, 1996. • [Yang. WA 05] A Do. S-Limiting Network Architecture, Xiaowei Yang, David Wetherall, and Thomas Anderson, SIGCOMM 2005. • [Juels. B 99] Client puzzles: a cryptographic countermeasure against connection depletion attacks, Ari Juels and John Brainard. ISOC NDSS 1999. • [Gunter. KTV 04] Do. S Protection for Reliably Authenticated Broadcast, Carl A. Gunter, Sanjeev Khanna, Kaijun Tan, and Santosh Venkatesh. NDSS 2004. • [Walfish. VBKS 06] DDo. S Defense by Offense, Michael Walfish, Mythili Vutukuru, Hari Balakrishnan, David Karger, and Scott Shenker. SIGCOMM 2006. • [Khanna. VFKG 08] Adaptive Selective Verification, Sanjeev Khanna, Santosh S. Venkatesh, Omid Fatemieh, Fariba Khan, and Carl A. Gunter. IEEE INFOCOM 2008. • [Kandula. KJB] Botz-4 -Sale: Surviving Organized DDo. S Attacks That Mimic Flash Crowds, Srikanth Kandula, Dina Katabi, Matthias Jacob, Arthur W. Berger. NSDI 2005 37

Discussion • Could the Internet be designed differently to thwart Do. S? • Which resource is best for an adversary to prove: valid address, computational power, bandwidth access, humanity, or something else? • Does the end-to-end argument apply to DDo. S defense? 38