1. Computer Security Heartbleed Bug Tutorial on Creating Certificates SSH
Perfect Forward Secrecy
Kerberos

2. OpenSSL “Heartbleed” Bug
Announced April, (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.

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

4. Illustration
From

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)*/

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

7. Heartbleed Vulnerability
Can extract private information stored in the virtual address space of the process, including private keys, p, q, p-1, q-1, d. 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. Akamai patch: move private keys to a “secure heap” area in virtual memory that is not near to the normal heap. Widely agreed to be a catastrophic security failure. Moral: check input data carefully before acting!

8. Acting as Your own Certificate Authority (CA)
1. a. Create public/private root keys for CA
b. Create self-signed root certificate
2. a. Create public/private intermediate keys
b. Create intermediate certificate signing request (CSR)
c. Sign intermediate certificate
3. a. Create public/private key for domain
b. Create CSR for domain
c. Sign certificate for domain using intermediate private key
Might do this when setting up secure web sites within a corporate intranet.
CPS 290

9. Create Files and Directories
index.txt stores database of certificates created
serial holds serial number of next certificate
CPS 290

10. Create Configuration File
Strict policy requires organization names in parent and child certificates to match, e.g., when used in intranet.
CPS 290

11. Create Root Public/Private Keys
Private key is encrypted using pass phrase as key to AES256 algorithm.
CPS 290

12. Create Root Certificate
-x509 indicates self-signed certificate
sha256 algorithm used to create message digest (hash) of certificate, which is then (self) signed
CPS 290

13. Examine the Root Certificate
who signed it
CPS 290

14. redundant to specify Signature Algorithm again
signed hash of everything above
CPS 290

15. CPS 290

16. Create Public/Private Intermediate Keys
CPS 290

17. Create Intermediate CSR
sha256 digest (hash) of applicant information signed with root private key – can check that it can be decoded with root public key
CPS 290

18. Sign Intermediate Certificate
CPS 290

19. Examine Signed Intermediate Certificate
CPS 290

20. CPS 290

21. CPS 290

22. Verify Signed Certificate Using Root Certificate
After signing the intermediate certificate, hide the root certificate’s private key somewhere very secure (e.g., off-line).
Use intermediate certificate with short validity period to sign other certificates.
CPS 290

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

24. Create Public/Private Keys for Domain
CPS 290

25. Create CSR for Domain www.example.com
CPS 290

26. Sign Certificate for Domain
CPS 290

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

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

29. SSH v2 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.

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

31. SSH v2 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 3DES, Blowfish, AES, or Arcfour begins.
CPS 290

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

33. Kerberos A key-serving system based on Private-Keys (DES). Assumptions
Built on top of TCP/IP networks
Many “clients” (typically users, but perhaps software)
Many “servers” (e.g. file servers, compute servers, print servers, …)
User machines and servers are potentially insecure without compromising the whole system
A kerberos server must be secure.
CPS 290

34. Ticket Granting Server
Kerberos (kinit)
Kerberos
Authentication
Server
Ticket Granting Server
(TGS) 2 1 3 4
Service Server
(S)
Client
(C) 5
Request ticket-granting-ticket (TGT)
<TGT>
Request server-ticket (ST)
<ST>
Request service
CPS 290

35. Kerberos V Message Formats
C = client S = server K = key or session key
T = timestamp V = time range
TGS = Ticket Granting Service A = Net Address
Ticket Granting Ticket: TC,TGS = TGS,{C,A,V,KC,TGS}KTGS
Server Ticket: TC,S = S, {C,A,V,KC,S}KS
Authenticator: AC,TGS = {C,T}KC,TGS
Authenticator: AC,S = {C,T}KC,S
Client to Kerberos: C,TGS
Kerberos to Client: {KC,TGS}KC, TC,TGS
Client to TGS: TC,TGS , S, AC,TGS
TGS to Client: {KC,S}KC,TGS, TC,S
Client to Server: AC,S, TC,S
Possibly repeat
CPS 290

36. Kerberos Notes All machines have to have synchronized clocks
Must not be able to reuse authenticators
Servers should store all previous and valid tickets
Help prevent replays
Client keys are typically a one-way hash of the client’s password + salt. Clients do not store these keys.
Kerberos 5 uses cipher block chaining (CBC) for encryption - Kerberos 4 was insecure in part because it used a nonstandard propagating CBC (PCPC)
CPS 290