Computer Security Heartbleed Bug Key Exchange SSH Perfect

Computer Security Heartbleed Bug Key Exchange SSH Perfect Forward Secrecy Page 1

Open. SSL “Heartbleed” Bug Announced April, 2014. (But bad code checked in December 31, 2011!) Exploits a programming mistake in the Open. SSL 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 Heartbeat. Request message containing a payload to the other endpoint (e. g. a Web server). The server then sends back a Heartbeat. Reply message containing the same payload. “Buffer over-read” error caused by a failure to check for an invalid read-length parameter. Page 2

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

Illustration From http: //www. theregister. co. uk/2014/04/09/heartbleed_explained/ Page 4

Broken Open. SSL Code struct ssl 3_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 */ … } SSL 3_RECORD; /* Read type and payload length first */ hbtype = *p++; /* message type goes in hbtype, p now points to length */ n 2 s(p, payload); /* copies length into variable payload, adds 2 to p */ pl = p; /* Enter response type, length and copy payload */ *bp++ = TLS 1_HB_RESPONSE; /* set type to response */ s 2 n(payload, bp); /* write payload (length) to memory, add 2 to p */ memcpy(bp, pl, payload); /*copy payload bytes from memory (up to 64 K)*/ Page 5

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

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 the virtual address space of the process, such as passwords. All Web sites using Open. SSL (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. Akamai patch: move private keys to an area in physical memory that never has virtual memory mapped to it. Widely agreed to be a catastrophic security failure. Moral: check input data carefully before acting! Page 7

Technologies for Protecting Private Keys 1) Hardware device that performs cryptographic operations for the processor. Private key cannot be read from the device. 2) Secure multiparty computation: multiple servers must collaborate to perform cryptographic operations. No one server can learn anything about the private key unless all collude. CPS 290 Page 8

Diffie-Hellman Key Exchange A group (G, *) and a primitive element (generator) g is made public. – Alice picks a random a, and sends ga mod p to Bob – Bob picks a random b and sends gb mod p to Alice – Both compute the shared key gab mod p 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? Page 9

Person-in-the-middle attack ga Alice gc Mallory gd Key 1 = gad Bob gb Key 1 = gcb Mallory gets to listen to everything. Page 10

SSH Applications Secure Shell (SSH): Replacement for insecure telnet, rlogin, rsh, rexec, which sent plaintext passwords over the network! Page 11

SSH Applications Port forwarding (email example): Log in to linux. cs. duke. edu. Forward anything received locally (phoenix) on port 25 to linux. cs. duke. edu on port 25. Useful if “phoenix” is not a trusted email relayer but “linux” is. “phoenix” email program configured to use phoenix as relayer Page 12

SSH v 2 Authentication • Server has a permanent “host” public-private key pair (RSA or DSA). Public key typically NOT signed by a certificate authority. Client warns if public host key changes. • User can authenticate by sending password to server or using a public-private key pair. • User’s private key has optional passphrase. If so, the private key is encrypted using the passphrase as an AES encryption key and stored on the client’s machine. • If using keys, client signs a block of data including session ID, user name, and user’s public key with user’s private key; server authenticates with user’s public key. • Advantage of using public/private key authentication: if server is compromised, only client’s public key is compromised. Page 13

SSH v 2 Session Encryption • Diffie-Hellman is used to exchange session key. – Server selects g and p (group size) and sends to client. – Client and server create DH private keys a and b. Client sends public DH key ga. – Server sends public DH key gb and signs hash of DH shared secret gab and 12 other values with its private “host” key. – Client verifies signed shared secret using public key. • Symmetric encryption using 3 DES, Blowfish, AES, or Arcfour begins. CPS 290 Page 14

Why Combine RSA and Diffie-Hellman? Why doesn’t the client just send a symmetric key to the server, encrypted with the server’s public key? Because if the server’s private key is later compromised, previous communications encrypted with the public key can be decrypted, revealing the symmetric key. Then all communications encrypted with the symmetric key can also be decrypted! To prevent this attack, Diffie-Hellman ensures that the symmetric key is never transmitted, even in encrypted form, and the client and server discard the symmetric key gab after the session is over. RSA is used for authentication to prevent the man-in-the-middle attack. SSL/TLS provides this option too: DHE_RSA key exchange “Perfect forward secrecy” Page 15