CPS 290.2 Computer Security
Tutorial on Creating Certificates
SSH
Kerberos
CPS 290
Page 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 www.example.com
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
index.txt stores database of certificates created
serial holds serial number of next certificate
CPS 290
Page 3
Create Configuration File
Strict policy requires
organization names in parent
and child certificates to match,
e.g., when used in intranet.
CPS 290
Page 4
Create Root Private Key
Private key is encrypted using pass phrase as key
to AES256 algorithm.
CPS 290
Page 5
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
Page 6
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
sha256 digest (hash) of applicant information signed with
intermediate private key – can check that it can be decoded
with intermediate public key
CPS 290
Page 11
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 www.example.com
CPS 290
Page 18
Sign Certificate for Domain
CPS 290
Page 19
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 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.
• User can authenticate by sending password or using publicprivate 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.
CPS 290
Page 20
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 (email 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 email relayer but “linux” is.
“phoenix” email program configured to use phoenix as relayer
CPS 290
Page 23
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
Page 24
Kerberos (kinit)
Kerberos
Authentication
Server
2
1
Client
(C)
1.
2.
3.
4.
5.
3
Ticket Granting Server
(TGS)
4
5
Service Server
(S)
Request ticket-granting-ticket (TGT)
<TGT>
Request server-ticket (ST)
<ST>
Request service
CPS 290
Page 25
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,S = {C,T}KC,S
1.
2.
3.
4.
5.
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
Possibly
repeat
Page 26
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.
CPS 290
Page 27