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

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

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

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

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

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

7. Examine the Root Certificate
who signed it
CPS 290

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

9. CPS 290

10. Create Private Intermediate Key
CPS 290

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

12. Sign Intermediate Certificate
CPS 290

13. Examine Signed Intermediate Certificate
CPS 290

14. CPS 290

15. CPS 290

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

17. Create Private Key for Domain
CPS 290

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

19. Sign Certificate for Domain
CPS 290

20. Protecting Private Keys
1) Store keys that are rarely used, e.g., private root key, off-line. 2) Hardware device that performs cryptographic operations for the processor. Private key cannot be read from the device. 3) 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

21. SSH
Server has a “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 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

22. 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
“Perfect forward secrecy”
CPS 290

23. SSH User Authentication
User can authenticate by sending password or using public-private key pair. 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.
SSHv1: If using keys, server sends “challenge” signed with users public key for user to decode with private key.
SSHv2: 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.
Why did SSHv2 replace solving a challenge with signing a body of public or innocuous data? Concern that the server could trick the client into decrypting something private.
CPS 290

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

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

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

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

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

29. 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, e.g., DES-CBC-MD5, of the client’s password + salt (random data). Clients do not store these keys – a key is created when the client logs in. These keys are private and not sent over the network.
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