1 / 14

CPS 290 Computer Security

Learn about the Heartbleed bug that exploits a TLS implementation flaw in OpenSSL, leading to severe RSA key extraction vulnerabilities. This text dives into the Heartbleed announcement, protocol details, and the impact on web security. Understand the intricacies of RSA encryption, including RSA key exchange, Diffie-Hellman protocols, and potential vulnerabilities. Take a closer look at the performance and security considerations of RSA encryption, highlighting the risks and best practices in utilizing this cryptographic system.

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. • 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. 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. CPS 290

  5. 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

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

  7. 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

  8. 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

  9. 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 (because (n) = 0 mod (n)) • Why is this argument not quite sound? • What if m  Zn* then m(n) 1 mod n • Answer 1: Not hard to show that it still works. • Answer 2: jackpot – you can factor n using Euclid’s alg. CPS 290

  10. 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

  11. 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

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

  13. 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

  14. 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