1 / 17

CPS 290 Computer Security

This article analyzes the Heartbleed bug in the RSA key exchange protocol, discussing its impact on security and performance. It also explores the vulnerabilities and fixes associated with the bug.

baoc
Download Presentation

CPS 290 Computer Security

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. CPS 290 Computer Security Heartbleed Bug Key Exchange RSA Analysis RSA Performance CPS 290

  2. OpenSSL “Heartbleed” Bug • Announced April, 2014. (But bad code checked in December 31, 2011!) • Exploits a programming mistake in the OpenSSL implementation of the TLS “heartbeat hello’’ extension. • Heartbeat protocol is used to keep a TLS connection alive without continuously transferring data. • One endpoint (e.g., a Web browser) sends a HeartbeatRequest message containing a payload to the other endpoint (e.g. a Web server). The server then sends back a HeartbeatReply message containing the same payload. • “Buffer over-read” error caused by a failure to check for an invalid read-length parameter. CPS 290

  3. From RFC 6520 • Heartbeat Request and Response Messages • The Heartbeat protocol messages consist of their type and an arbitrary • payload and padding. • struct { • HeartbeatMessageType type; • uint16 payload_length; • opaque payload[HeartbeatMessage.payload_length]; • opaque padding[padding_length]; • } HeartbeatMessage; • The total length of a HeartbeatMessage MUST NOT exceed 2^14 or • max_fragment_length when negotiated as defined in [RFC6066]. • type: The message type, either heartbeat_request or heartbeat_response. • payload_length: The length of the payload. • payload: The payload consists of arbitrary content. • padding: The padding is random content that MUST be ignored by the receiver. • Problem: no check that payload_length matches the actual length of the payload CPS 290

  4. Illustration • From http://www.theregister.co.uk/2014/04/09/heartbleed_explained/ CPS 290

  5. Broken OpenSSL Code • struct ssl3_record_st { /* generic struct used to store message */ • unsigned int length; /* How many bytes available */ /* ignore */ • unsigned int off; /* ignore */ • unsigned char *data; /* pointer to the record data */ /* ignore */ • … • } SSL3_RECORD; • /* Read type and payload length first */ • hbtype = *p++; /* message type goes in hbtype, p now points to length */ • n2s(p, payload); /* copies length into variable payload, adds 2 to p */ • pl = p; • /* Enter response type, length and copy payload */ • *bp++ = TLS1_HB_RESPONSE; /* set type to response */ • s2n(payload, bp); /* write payload (length) to memory, add 2 to p */ • memcpy(bp, pl, payload);/*copy payload bytes from memory (up to 64K)*/ CPS 290

  6. The Fix • hbtype = *p++; • n2s(p, payload); • if (1 + 2 + payload + 16 > s->s3->rrec.length) • return 0; /* silently discard per RFC 6520 sec. 4 */ • pl = p; CPS 290

  7. Heartbleed Vulnerability • RSA private keys p, q, p-1, q-1, d can be extracted by the attacker, as can anything else in the right portion of server memory, such as passwords. • All Web sites using OpenSSL (e.g., using Apache, nginx servers) should have their certificates revoked, and new certificates issued. • Akamai was informed before the bug was announced publicly and released a patch, but (oops!) there was a bug in that too. • Widely agreed to be a catastrophic security failure. • Moral: check input data carefully before acting! CPS 290

  8. Diffie-Hellman Key Exchange • A group (G,*) and a primitive element (generator) g is made public. • Alice picks a, and sends ga to Bob • Bob picks b and sends gb to Alice • The shared key is gab • Note this is easy for Alice or Bob to compute, but assuming discrete logs are hard is hard for anyone else to compute. • Can someone see a problem with this protocol? CPS 290

  9. ga • gc • Alice • Mallory • Bob • gd • gb • Key1 = gad • Key1 = gcb Person-in-the-middle attack • Mallory gets to listen to everything. CPS 290

  10. RSA • Invented by Rivest, Shamir and Adleman in 1978 • Based on difficulty of factoring. • Used to hide the size of a group Zn* since: • Factoring has not been reduced to RSA • an algorithm that generates m from c does not give an efficient algorithm for factoring • On the other hand, factoring has been reduced to finding the private-key. • there is an efficient algorithm for factoring given one that can find the private key. CPS 290

  11. RSA Public-key Cryptosystem • What we need: • p and q, primes of approximately the same size • n = pq(n) = (p-1)(q-1) • e  Z (n) • d = inv. of e in Z (n) i.e., d = e-1 mod (n) • Public Key: (e,n) • Private Key: d • Encode: • m  Zn • E(m) = me mod n • Decode: • D(c) = cd mod n CPS 290

  12. RSA continued • Why it works: • D(c) = cd mod n • = med mod n • = m1 + k(p-1)(q-1) mod n • = m1 + k (n) mod n • = m(m (n))k mod n • = m (by Euler’s Theorem, m k(n) mod n = m0 mod n, if m and n are relatively prime.) • What if m and n share a factor? Then Euler’s theorem doesn’t guarantee that mk(n)= 1 mod n • Answer 1: Special case, still works, use Chinese Remainder Theorem to prove instead. • Answer 2: jackpot – you can factor n using Euclid’s alg. CPS 290

  13. RSA computations • To generate the keys, we need to • Find two primes p and q. Generate candidates and use primality testing to filter them. • Find e-1 mod (p-1)(q-1). Use Euclid’s algorithm. Takes time log2(n) • To encode and decode • Take me or cd. Use the power method.Takes time log(e) log2(n) and log(d) log2(n) . • In practice e is selected to be small so that encoding is fast. CPS 290

  14. Security of RSA • Warning: • Do not use this or any other algorithm naively! • Possible security holes: • Need to use “safe” primes p and q. In particular p-1 and q-1 should have large prime factors. • p and q should not have the same number of digits. Can use a middle attack starting at sqrt(n). • e cannot be too small • Don’t use same n for different e’s. • You should always “pad” CPS 290

  15. RSA Performance • Performance: (600Mhz PIII) (from: ssh toolkit): CPS 290

  16. RSA in the “Real World” • Part of many standards: PKCS, ITU X.509, ANSI X9.31, IEEE P1363 • Used by: SSL, PEM, PGP, Entrust, … • The standards specify many details on the implementation, e.g. • e should be selected to be small, but not too small • “multi prime” versions make use of n = pqr…this makes it cheaper to decode especially in parallel (uses Chinese remainder theorem). CPS 290

  17. Factoring in the Real World • Quadratic Sieve (QS): • Used in 1994 to factor a 129 digit (428-bit) number. 1600 Machines, 8 months. • Number field Sieve (NFS): • Used in 1999 to factor 155 digit (512-bit) number. 35 CPU years. At least 4x faster than QS • Used in 2003-2005 to factor 200 digits (663 bits) 75 CPU years ($20K prize) CPS 290

More Related