Admin

CCT7H4:Network
Security Book - Crypt Decrypt

Certificates and PKI, Certificates and PKI ch 16,17,18

SSL and IPSec
SSL ch 20

IPsec ch 21 (and appendix B)

Described in many other books

Review Lecture Quiz

Wednesday May 5th 14:00 C1.01

My Security review What is a digital signature?

(Java review)

Public Keys Authenticate

the Public Key
Whereas secret key systems have the
problem of key distribution For Alice to talk securely to Bob, she just
needs to read his public key from a public
Public key systems have a problem of trust directory, but needs authentication
that a public key really belongs to a certain
person Use a Trusted Third Party (TTP)

Resolution leads to certificates and trust Someone (maybe a central Certificate

chains. Digital signatures form the basis of Authority) that Alice trusts, guarantees that
certificates the public key really is Bob's
 Public-key Certificates Digital Certificate
Contains Terminology
the public key

a string saying whose key it is

Issuer - who signs the certificate, generally
Effectively a statement “I attach Alice’s the CA
public key to this certificate and have signed
Subject - whose public key is contained here
(the hash) with my private key”
Time Limit - the expiry date of the
Signed by someone Alice trusts (TTP)
certificate
the public key of the signer (needed to
check the signature) is assumed to be
well known

Managing Certificates SSL Certificates

To put in a secure (https) web server in
The administrative framework used to order to authenticate the domain name
manage public key certificates is known as a
“public key infrastructure” Signed by the TTP = “certification
authority” (CA). Nowadays Verisign
Common PKI’s
How to verify the certificate?
SSL based on X.509 certificates embedded
in your browser use the public key of the CA to verify the
signature on the certificate
PGP email based on “web of trust”
this public key is available on your
browser (difficult to forge)

Browser Certificates Verisign

class 3
certificate
in Firefox

Root certificates in Firefox - lots of independent

public and private CA’s
 Trust Trust Chains
The certificate has been signed by a CA
You must evaluate the degree to which you trust them To check that the certificate is not forged
What realistic basis do you have to trust Verisign? use the CA's public key to verify the signature
you can get a class 1 ID just by filling out a web
form and paying a fee - the key is sent by email, so You need to be certain of the CA's public key
really you only know that the email address is
genuine via another certificate signed by a different,
maybe more trusted, CA (levels of Verisign CA’s)
class 3 ID requires appearance before a notary
(Class1-Class3 use the same cryptography) highest level CA must be trusted by everyone!
What is the $ limitation the CA accept for The root certificate of a CA is a self signed
failure?... in practice the CA is not responsible if the certificate
subject misuses the certificate

Lifetime of Certificates Certificate Revocation

A key may become compromised
Keys are changed in the normal course of
events Need more rapid revocation than just waiting for the
certificate to expire
A public key certificate should not state that
the key is indefinitely valid Publish a Certificate Revocation List (CRL)!

Hence include an expiry date in the Check this list when you check the certificate
certificate
Check this list before a certificate can be renewed
Typical lifetime of a year for internet by extending its lifetime
applications
Expensive but vital complication, sometimes omitted....

Certificate Management
X.509 Certificate Format
in Java and OpenSSL
Widely supported (Microsoft, Verisign...)! Java provides a command line program: keytool to
generate and manage certificates and private keys
But not very appropriate....
stored in a database known as a keystore
Horrid structure details – eg names
OpenSSL also has command lines for certificates
X.509 names are like: C=US, O=companyname,
Lab session!
OU=researchdept, CN=Alice. Even worse at
detailed formal level ASN.1 and binary BER Only use to generate self signed certificates
Not easy to incorporate email or DNS names in Use of signing for code distribution
this scheme, leading to workarounds that tend
to expose security flaws OS generally have some similar native application
 PKI in practice Pretty Good Privacy
Do you check certificates when prompted by
browser? PGP is a different approach to certificate
Browsers don't check expiry very carefully management
(due to many servers using expired Much less bureaucracy, users manage their
certificates following price increases) own certificates and do not rely on a CA
UoW certificates often outdated Certificates/keys just as strong as X.509 but
Internet Explorer library bug (didn't check use a different (incompatible) format
the CA tag) History: Zimmermann 1991 mainly for emails
Verisign mistake Web of Trust

In PGP, user has to

Summary
make decisions

You receive a certificate from Frank, and you

don’t know Frank, but you do trust Bob and Certificates - what they are
Bob says that Alice is trustworthy and Alice
PKI: the sum total of everything necessary
vouches for Frank.
to use public/private key crypto
You have to decide whether to trust Frank
or not

Secure Communication Link-by-Link

Mutual authentication and a session key Easiest at physical layer in hardware
In principle at any layer in OSI model
If synchronous and always on, eavesdropper
In practice can't even do traffic analysis – can't tell
Low layers, encrypt everything when individual messages start/end
Link-by-link encryption
But every link must be separately encrypted
Higher layers and must protect every router where
End-to-End encryption decrypted version is available for routing
Different requirements from encrypting databases Awkward – mainly military use
for archiving
 End-to-End Which Layer for SSL/IPsec
Only encrypt the payload – remains encrypted SSL Applications
from sender to receiver
TCP
(later will distinguish host-to-host and TCP OS
IPSec
firewall-to-firewall as different kinds of end-
IP
to-end) IP
Traffic analysis may be possible since header is Lower layers NIC Lower Layers
plaintext
Individuals (or company firewalls) must have keys
SSL operates above TCP IPSec is within the OS
Examples covered:
IPSec at the IP layer The OS doesn't change. Applications unchanged.
SSL at the application layer

Which layer for end-to-end? What is SSL?

Recall that IP stack is within the OS
SSL is the protocol used for most secure
SSL operates above TCP transactions over the Internet

No need to change OS For example, if you want to buy a book at amazon…

A superset of usual socket API You want to be sure you are dealing with Amazon
(authentication)
Easy to port applications
Your credit card information must be protected in
IPSec transit (confidentiality and/or integrity)
Within the OS Amazon doesn’t care who you are, as long as you
have money (authentication need not be mutual)
All applications protected without modification

SSL-like Protocol SSL Design

Secure communication without prior negotiation or
I want to talk help from 3rd parties
A hybrid scheme of public key to set up secret
Here’s my Certificate session key
l B
Client i o Server Choice of cryptographic algorithms by client and
{KAB}bob server - negotiated during handshake
c b
e Communication in each direction can be authenticated,
Protected HTTP encrypted or both
in practice only server is authenticated to client
Is Alice sure she is talking to Bob? Efficiency with multiple HTTP1.0 connections by
Is Bob sure he is talking to Alice? avoiding expensive public key operations
 Simplified SSL Protocol SSL Handshake
I want to talk, ciphers I support, RA
Alice lists cipher possibilities and sends random RA
Client A
Certificate, cipher I choose, RB Server Bob chooses cipher, sends his certificate and his
Choose l B random RB
secret S, Compute
Key K= i
{S}B,keyed hash of handshake messages
o Key K=
Alice chooses a random pre-master secret S and
f(S,RA,RB)
f(S,RA,RB)!
c b sends it encrypted with Bob's public key. Also sends
e keyed hash of handshake messages
hash of master secret K and of handshake messages
to avoid tampering
Protected Data Bob proves he was able to extract S (ie knows the
private key)

SSL Keys
Ciphers
Supported Master secret key is based on the three
random numbers RA, RB, S (sent encrypted)
Use to generate 3 session keys for each side

Encryption key
Integrity key (HMAC key)!
Initialization vector (for block cipher CBC)!
Use separate keys for sending and receiving - total
of 6 keys

Message
Authentication Codes (HMAC)!
Configuration options
Key Exchange
Efficient for authentication on secure channels (used RSA, Ephemeral Diffie Hellman,...
in both IPSec and SSL)
Authentication
Alice and Bob set up shared secret keys for integrity
RSA, DSA
Alice combines message M with the key and works
Symmetric Ciphers
out the digest h (called HMAC or keyed hash)
RC4, triple DES, AES, IDEA....
Alice sends M and h to Bob
Cryptographic Hash Function
Bob does the same to verify
HMAC-SHA, HMAC-MD5
Authentication in Normal Client Authentication
Deployment Generally not authenticated

Only server has a certificate For e-commerce, server can rely on the credit card

Server is authenticated to client Often use some kind of password system - separate
from SSL
PKI:
SSL does support client authentication
Client browser is configured with public keys of
organizations the browser vendor regards as Server sends a “certificate request” in step 2
trustworthy The client needs to have a certificate recognised
Server certificate is usually signed by one of by the server
these, if not, user is presented with a pop-up National grid service set up their own CA and use
this mechanism for authentication

Man in the Middle Java JSSE

Attack Java Secure Socket Extension (JSSE)!
Trudi sits in the middle, and can send her
Now a standard part of J2SDK
own certificate to Alice rather than Bob’s
Support for secure HHTP requests known as HTTPS or
Then Alice’s browser fails to verify the
HTTP over SSL
certificate (assuming it is not signed by
Verisign) and pops up a warning javax.net.ssl package
What does Alice do? If only interested in HTTPS, use the
HttpsURLConnection class
in all probability, ignores the warning, so
the attack is successful Or use the raw (JSSE) sockets - quite similar API to
ordinary sockets

Raw JSSE Sockets SSLClient.java

Instead of usual Socket constructor, use an
SSLSocketFactory SocketFactory factory = SSLSocketFactory.getDefault();

// Using socket factory, get SSL socket to port on host

Obtain input/output stream as usual and send HTTP SSLSocket s=
GET request
(SSLSocket)factory.createSocket(hostname,HTTPS_PORT);

Examine the credentials received to make sure that String[] supported = s.getSupportedCipherSuites();

you are talking to the host you think you are. Use for(String ciphertype : supported)
socket.getSession()and getPeerCertificates() System.out.println(ciphertype);

SSLSession sess = s.getSession();

SSLClient or HTTPSClient.java
Certificate[] cert = sess.getPeerCertificates();
Server side is harder - need certificates for(Certificate c : cert)

System.out.println(c);
SecureEchoServer.java and SecureEchoClient.java
 IPSec IPSec: Uses
RFC2401 overview (other RFC's on details) 1998
Transparent to transport layer/users, so
At IP layer, especially relevant to Ipv6 politics supports various applications: remote login, e-
So available to TCP, UDP, ICMP etc mail, web access, file transfer etc

Open security architecture with extendable Remote users to safely access a network VPN
encryption and authorization services Two users transferring data
Implemented in security gateways (firewalls) and Interconnecting two networks
individual hosts

Two parts of IPSec:

IPSec and Complexity
IKE and ESP/AH
IPSec is a complex protocol IKE: Internet Key Exchange
Over-engineered Mutual authentication
Lots of generally useless extra features Establish shared symmetric key
Flawed ESP/AH
Some serious security flaws ESP: Encapsulating Security Payload ! for
Interoperability is serious challenge encryption and/or integrity of IP packets

Defeats the purpose of having a standard! AH: Authentication Header ! integrity only

IKE IKE Phase 1

IKE has 2 phases Four different “key” options

Phase 1 ! IKE security association (SA) Public key encryption (original version)

Phase 2 ! AH/ESP security association Public key encryption (improved version)

Phase 1 is comparable to SSL session Public key signature

Phase 2 is comparable to SSL connection Symmetric key

But no obvious need for two phases in IKE For each of these, two different “modes”

If multiple Phase 2’s do not occur, then it is Main mode

more expensive to have two phases!
Aggressive mode
 IKE Key Options IKE Phase 1
Why both public key encryption and public key All variants use ephemeral (destroy parameters
signatures? after use) Diffie-Hellman to establish the session
key
Always know your own private key
Achieves perfect forward secrecy (PFS)
May not (initially) know other side’s public key
Just discuss 2 of 8 phase 1 variants
In the signature version Alice does not know Bob’s
public key beforehand and the protocol manages to Public key signatures (main and aggressive
retrieve it without wasting a message modes)

Digital Signature (Main Mode) Signature (Aggressive Mode)

IC, CP
IC, RC, CS IC, “Alice”, ga mod p, RA, CP
IC, RC, ga mod p, RA
IC, RC, “Bob”, RB,
IC,RC, gb mod p, RB
gb mod p, CS, proofB
IC,RC, E(“Alice”, proofA, K)
Alice IC,RC, E(“Bob”, proofB, K) Bob IC, RC, proofA
Alice Bob
CP = crypto proposed, CS = crypto selected
IC = initiator “cookie”, RC = responder “cookie” Simpler than main mode since not trying to
K = h(IC,RC,gab mod p,RA,RB) protect identities
SKEYID = h(RA, RB, gab mod p) Cannot negotiate g or p
proofA = [h(SKEYID,ga,gb,IC,RC,CP,“Alice”)]Alice

Main versus
IKE Phase 1 Summary
Aggressive Modes
Result of IKE phase 1 is

Main mode MUST be implemented Mutual authentication

Aggressive mode SHOULD be implemented Shared symmetric key

Creates interoperability issues IKE Security Association (SA)

Main mode is usually intended to hide But phase 1 is expensive (in public key and/or
identities main mode cases)

Developers of IKE thought it would be used

for lots of things ! not just IPSec, but...
 IKE Phase 2
IPSec
IC,RC,CP,E(hash1,SA,RA,K)
IC,RC,CS,E(hash2,SA,RB,K)
After IKE Phase 1, we have an IKE SA
IC,RC,E(hash3,K)
Alice Bob After IKE Phase 2, we have an IPSec SA

Both sides have a shared symmetric key

Key K, IC, RC and SA known from Phase 1
RA, RB are not from phase 1, so the phase2 key is new Now what?

Proposal CP includes ESP and/or AH We want to protect IP datagrams

Hashes 1,2,3 depend on SKEYID, SA, RA and RB IPSec provides two kinds of modes and
Keys derived from KEYMAT = h(SKEYID,RA,RB,junk) two kinds of header

IP Reminder IPSec Transport Mode

IP datagram is of the form:
IP header data
IP header data

Where IP header is: IP header ESP/AH data

Data may
encapuslate Transport mode designed for host-to-host
TCP which might Efficient: adds minimal amount of extra header
contain HTTP The original header remains so a passive
attacker can see who is talking

IPSec Tunnel Mode IPSec Security

What kind of protection?
IP header data Confidentiality? (triple DES-CBC or AES-CBC)
Integrity? (HMAC-SHA1)
new IP hdr ESP/AH IP header data
Both?
Tunnel mode for firewall to firewall traffic
What to protect?
Original IP packet encapsulated in IPSec
Data?
Original IP header not visible to attacker
New header from firewall to firewall Header?
Attacker does not know which hosts behind Both?
the firewall are talking ESP/AH do some combinations of these
 Integrity of the IP
AH vs ESP Headers
Header
AH: Authentication Header

Integrity only (no confidentiality) But routers must look at the IP header - it
exists to route packets!
Integrity-protect everything beyond IP
header and some fields of header AH protects immutable fields in IP header

ESP: Encapsulating Security Payload Cannot integrity protect all header fields

Integrity and confidentiality TTL, for example, must change

Protects everything beyond IP header ESP does not protect IP header at all

Why bother with AH? IPSec and NAT

Network Address Translation (NAT), fakes up extra IP
addresses (and thereby postpones Ipv6)
ESP allows a “NULL” encryption that still integrity
protects the data -- sounds like AH IPSec tunnel mode can't go through NAT box
because the NAT box needs to change the IP
But AH also protects the immutable header fields addresses inside the encrypted data
If ESP encrypted, firewall cannot look inside data: Problems for IPSec transport mode because the IP
The firewall sees ESP header, but does not address is part of the authenticated TCP or UDP
know whether null encryption is used checksum. Also can’t change the TCP port numbers
due to integrity
End hosts know, but not firewalls
NAT Traversal, NAT-T, another layer of encapsulation

Why Does AH Exist? Summary: SSL vs IPSec

Both provide encryption, integrity protection and
The reasons above for keeping AH are weak, authentication
the real reason why AH exists (according to
Kaufman,Perlman&Speciner) SSL relatively simple and well designed

At one IETF meeting “someone from IPSec overly complex with flaws
Microsoft gave an impassioned speech
SSL built into web early on and primary use
about how AH was useless…”
remains secure web transactions
“…everyone in the room looked around
IPSec often used for VPN and required for IPv6
and said `Hmm. He’s right, and we hate AH
also, but if it annoys Microsoft let’s leave Reluctance to either retrofit applications for SSL
it in since we hate Microsoft more than or to consistently use IPSec due to complexity
we hate AH.” and interoperability issues