CPS Computer Security Tutorial on Creating Certificates SSH Kerberos CPS 290Page 1

Acting as Your own Certificate Authority (CA) 1. a. Create private root key for CA b. Create self-signed root certificate 2. a. Create private intermediate key b. Create intermediate certificate signing request (CSR) c. Sign intermediate certificate 3. a. Create 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 Page 2

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

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

Create Root Private Key CPS 290 Page 5 Private key is encrypted using pass phrase as key to AES256 algorithm.

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

Examine the Root Certificate CPS 290 Page 7

CPS 290 Page 8

CPS 290 Page 9

Create Private Intermediate Key CPS 290 Page 10

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

Sign Intermediate Certificate CPS 290 Page 12

Examine Signed Intermediate Certificate CPS 290 Page 13

CPS 290 Page 14

CPS 290 Page 15

Verify Signed Certificate Using Root Certificate CPS 290 Page 16

Create Private Key for Domain CPS 290 Page 17

Create CSR for Domain CPS 290 Page 18

Sign Certificate for Domain CPS 290 Page 19

CPS 290Page 20 SSH v2 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. Diffie-Hellman 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 g a. –Server sends public DH key g b and signs hash of DH shared secret g ab 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. User can authenticate by sending password or using public- private key pair. Private key has optional passphrase. If using keys, server sends “challenge” signed with users public key for user to decode with private key.

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 after the session is over. SSL/TLS provides this option too: DHE_RSA key exchange CPS 290 Page 21

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

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 phoenix as relayer CPS 290 Page 23

CPS 290Page 24 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 290Page 25 Kerberos (kinit) Kerberos Authentication Server Client (C) Service Server (S) Ticket Granting Server (TGS) Request ticket-granting-ticket (TGT) 2. 3.Request server-ticket (ST) 4. 5.Request service

CPS 290Page 26 C = client S = server K = key or session key T = timestamp V = time range TGS = Ticket Granting Service A = Net Address Ticket Granting Ticket: T C,TGS = TGS,{C,A,V,K C,TGS }K TGS Server Ticket: T C,S = S, {C,A,V,K C,S }K S Authenticator: A C,S = {C,T}K C,S 1.Client to Kerberos: C,TGS 2.Kerberos to Client: {K C,TGS }K C, T C,TGS 3.Client to TGS: T C,TGS, S, A C,TGS 4.TGS to Client: {K C,S }K C,TGS, T C,S 5.Client to Server: A C,S, T C,S Kerberos V Message Formats Possibly repeat

CPS 290Page 27 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 password. Clients do not keep these keys. Kerberos 5 uses CBC mode for encryption Kerberos 4 was insecure because it used a nonstandard mode.