CPS 290 Computer Security

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