Title: COEN 350
1COEN 350
2Communication Security
- Decision What Layer?
- Implemented at application level
- Application change
- OS does not change
- Implemented at TCP/IP level
- OS changes
- Applications do not change
3Communication Security
- Session Key Establishment
- Threat Session Hijacking
- Counter-measure Encryption
- Use Session key for each session
- Session key needs to be unpredictable
- Implementation of SSL used time, process id,
parent process id to concoct session key - Attacker could narrow search space to about 30b
of key. - Both partners should contribute to session key
- Threat Packet replay
- Counter-measure Sequence number
4Communication Security
- Perfect Forward Security
- Threat
- Eavesdropper captures traffic.
- Eavesdropper later acquires master key for both
communicants. - PFS Eavesdropper can still not encrypt data.
- Diffie Hellman key exchange provides PFS
- Counter-example
- Encrypting all messages with a public key of
partner - Kerberos
- Session key is inside ticket, encrypted with
long-term secret key - Sending session key encrypted with public key
5Communication Security
- Escrow-foilage
- Alice and Bob have to give their private keys to
an escrow agency. - Passive listener with those keys can still not
decrypt traffic between Alice and Bob
6Communication Security
- Denial of Service Protections
- Cookies
- Server can generate random looking cookies.
- Server can quickly verify that something is a
cookie. - Server hands out cookies to requestors.
- Requestors need to pass cookie along with all
traffic.
7Communication Security
- Denial of Service Attack Protection
- Puzzles
- Server creates puzzles
- Client needs to solve puzzle in order to get work
done. - Client does more work than server ? DOS attack is
harder
8Communication Security
- Replay prevention
- Use session keys
- Session Resumption
- Goal is avoiding costly initial encryption
exchange - Lotus Notes
- Server has secret that changes once a month.
- Server sends hash(client-name, server-secret) to
client after authentication. - Session key is calculated from this hash plus
nonces.
9Communication Security
- Negotiation of crypto-parameters
- Systems evolve
- Crypto-systems become breakable
- Newer crypto-systems demand larger resources.
- Potential Security Flaw
- Negotiating in bad faith, insisting on breakable
crypto-suites.
10Communication Security
- Endpoint identifier hiding
- Establish secure tunnel (via Diffie Hellman)
first. - Then authenticate.
- Man-in-the-middle gets caught in the second step.
- Can only find out one identity.
11IPSec
- RFC 1636 identified key areas where the internet
needs to be made more secure. - Spoofing Creating packets with false addresses.
- Eavesdropping / packet sniffing.
- True for both IPv4 and IPv6.
12IPSec
- Implemented below the transport layer.
- No application needs to be rewritten.
- Is part of the OS.
Applications
TCP
IPsec
IP
lower layers
13IPSec
- Provides confidentiality for IP connections
- Allows implementation of access policies
- Authenticates source IP addresses
- But not users.
14IPSec
- Transport Mode
- Adds IPSec information between IP Header and
remainder of packet. - Tunnel Mode
- Encapsulates the original IP header and packet.
- Adds new IP header and IPSec header
IP Header IPSec Header IP-payload Old
rest of packet
IP Header IPSec Header IP Header Secure IP Payload
15IPSec
- An IPSec packet in tunnel mode completely
encapsulates the payload. - IP Header is either an
- AH Authentication Header
- ESP Encapsulating Security Payload that tells
the user which Security Association to use.
IP Header IPSec header Secure IP Payload
16IPSec
- Developed by the Internet Engineering Task Force
IETF - Architecture
- ESP (Encapsulating Security Payload)
- AH (Authentication Header)
- Encryption Algorithm
- Authentication Algorithm
- Key Management
- DOI (Domain of Interpretation) (How to fit the
work together.)
17IPSec
- Security Association
- Cryptographically protected connection.
- Paradigm to manage authentication and
confidentiality between sender and receiver. - Unidirectional.
- IPSec header contains SPI (Security Parameter
Index) that identifies the security association. - Allows partner to look up the necessary data such
as the key in SA database.
18IPSec
- Security Association Database
- When X transmits to Y in IPSec, X looks up Y in
the SA database. - Provides key
- Provides SPI
- Security Parameter Index
- Provides algorithms to be used
- Provides sequence number
- When Y receives a transmission, Y uses the SPI
and the destination address to find the SA.
19IPSec
- Security Policy Database
- Specifies what to do with packets
- Dropping
- Forwarded and accepted without IPSec protection
- Forwarded and protected by IPSec
- Decision based on fields in the IPsec packet.
20IPSec
- Two types of IPsec headers.
- AH
- Authentication header.
- Provides integrity protection only.
- Allows firewalls to peek at TCP ports.
- ESP
- Encapsulating Security Payload
- Optional integrity protection
- Optional encryption
21IPSec
- Two modes
- Transport mode
- Adding IPsec information between IP header and
remainder of package. - Tunnel mode
- Keeps the original IP packet intact, but put it
into a new packet with new IP header and IPsec
data.
22IPSec
- Transport mode versus Tunnel mode
Original Packet IPsec Package in Transport Mode IPSec Package in Tunnel Mode
IP header rest IP header IPsec header rest new IP hdr IPSec IP header rest
23IPSec
IPsec in tunnel mode for a VPN IP srcR1,
dstR2 ESP IP srcA, dstB packet
24IPSec
- NAT
- Network address translation
- NAT boxes takes IP traffic from the outside.
- Based on port number, repackages packet to be
send to an internal address and vice versa. - Allows organization to make to do with few IP
addresses.
25IPSec
- NAT
- Have difficulties with incoming calls to dynamic
hosts. - Need to maintain routing table dynamically.
- Usually, need to be application-aware.
- Function as a limited, package-based firewall.
26IPSec
- NAT
- Have difficulties with programs like FTP.
- FTP uses normally two channels command channel
and data channel. - Client opens command channel.
- Packet to port 21, informs server of port on
which it is listening. - Server responds by opening a data channel from
port 20 to the clients listening port. - PASV mode
- Client sends PASV command to server.
- Server starts to listen on random port, gives
port to client in respond to PASV. - Client opens data channel to the new port.
27IPSec
- AH Header
- Next header position of protocol field of
encapsulated package - Payload length Size of AH header in words.
- SPI (Security Parameter Index)
- Sequence number Used by AH to recognize replayed
packages. Not identical with TCP package number. - Authentication data Cryptographic integrity
check on the payload data.
1B 1B 2B 4B 4B variable
Next header Payload length Unused SPI Sequence Number Authentication data
28IPSec
- AH
- Some IP header fields get reset by NATs and
routers. - Mutable fields are not covered by the integrity
check and can be changed by routers - Type of service
- Flags
- Fragment offset
- Time to live
- Header checksum
- Immutable fields cannot be changed
- Payload length
- Needed to reassemble fragmented AH packets.
29IPSec
- AH
- Immutable fields
- Destination address is protected by AH.
- NAT will change the destination address.
- Hence, IPSec /AH and NAT do not work well
together. - There is no way to predict the change at the
source. - In source routing, routers change the destination
address to the next field specified by source
routing. - AH can predict the destination address.
- An example of a mutable, but predictable field.
30IPSec
- ESP (Encapsulating Security Payload)
- SPI
- Sequence Number (same as for AH)
- IV Initialization Vector (used by some
cryptographic algorithms - Data protected data, possibly encrypted
- Padding needed to make data multiple of block
size. - Padding length
- Next header Protocol field in IPv4 or next
header in IPv6 - Authentication data Cryptographic integrity
check.
4 4 var. var. var. 1 1 var.
SPI Sequence number IV data padding padding length Next header / protocol type Authentication data
31IPSec
- AH protects the IP header itself.
- ESP protects everything beyond the ESP header.
- Hence AH provides additional (but useless?)
protection. - AH is less likely to fall under export
restrictions.
32IPSec
- TF-ESP (Transport-friendly ESP)
- Proposal to copy fields of interest of the
original header in clear. - Firewalls and routers can look at these
information. - Potential for information leak.
- Firewalls should not look at any data above layer
3. - But of course, they now do.
- IPSec protection is end-to-end, and intermediate
routers / firewalls cannot trust the cleartext
copies of these fields.
33IPSec IKE
- Internet Key Exchange
- Needed for
- mutual authentication
- to set up an SA
-
- Compromise based on Photuris and Skip
34Photuris
- Uses Cookies
- Different from web browser cookies.
- When Alice connects to Bob, Bob chooses a cookie
and sends it to Alice. - Bob only honors further requests from Alice with
the cookie. - Foils very simple DoS attacks.
- To keep cookie stateless, the cookie is a
function of Alices address and a secret known by
Bob only.
35Photuris
CA
CA, CB, crypto
CA, CB, gb mod p, crypto selected
CA, CB, gb mod p
CA, CB, Alice, sig of prev. message gab mod p
Alice
Bob
CA, CB, Bob, sig of prev. message gab mod p
36Photuris
- Alice chooses cookie CA in order to keep
different login attempts separated. - Bob uses a stateless cookie CB in order to keep
DoD attacks at bay. - Messages 3 and 4 consists of a Diffie-Hellman
encryption. - Messages 5 and 6 serve for authentication.
Encrypted with Diffie-Hellman key.
37Photuris
CA
CA, CB, crypto
CA, CB, gb mod p, crypto selected
CA, CB, gb mod p
CA, CB, Alice, sig of prev. messagegab mod p
Alice
Bob
CA, CB, Bob, sig of prev. messagegab mod p
38SKIP
- Simple Key Management for Internet Protocols
- Principals have
- Certified Diffie-Hellman public keys ga mod p
- Long-time use
- Private key a.
- Alice wants to talk to Bob
- Alice takes Bobs public key gb and raises it to
the ath power. - Bob takes Alices public key ga and raises it to
the bth power. - Both share the secret gab mod p.
39SKIP
- SKIP derives a key KAlice,Bob from the mutually
shared secret between Alice and Bob. - Such as the lower bits of gab mod p.
- Each packet is encrypted / authenticated with a
randomly generated key Kpacket. - The key Kpacket is encrypted with KAlice, Bob and
added to the packet. - The header of the packet is in clear text.
40SKIP
Clear IP Header KAlice,BobKpacket Kpacketpayload
41SKIP
- Changing a principals key is a difficult, but
needed operation. - Minimizes exposure of the key and makes
crypt-analysis more difficult. - Updating the master key prevents reusing
compromised traffic keys. - Each new key needs to be certified.
42SKIP
- Make the master key KAlice,Bob dependent on a
version that automatically updates - KAlice,Bob hash(gab,counter-value)
- Allows still principals to get a brand-new
certified key. - Prevents some replay attacks.
43IPSec IKE
- Phases
- Phase 1
- Does mutual authentication and establishes
session keys. - Known as KSAKMP SA / IKE SA
- Phase 2
- Establishes an ESP or AH SA
- Phase 1 is necessarily expensive.
- The two phases try to have phase 2 profit from a
phase 1 interchange used for another protocol,
connection,
44IPSec IKE
- Phase 1 IKE
- Aggressive mode
- Use a single crypto-proposal
- Main mode
- Negotiate the strongest crypto-proposal that both
parties can agree to.
45IPSec IKE
ga, Alice, crypto-proposal
gb, crypto-choice, Proof that Im Bob.
Bob
Alice
Proof that Im Alice
46IPSec IKE
crypto-suites I support
Crypto suites I choose.
ga
Alice
Bob
gb
gabAlice, Proof that Im Alice
gabBob, Proof that Im Bob
47IPSec IKE
- Key Types
- Pre-shared secret
- Public key for encryption / decryption
- Public key for signing
- 8 variants of Phase 1!!!
48IPSec IKE
- Phase 1 establishes two session keys
- Integrity key
- Encryption key for the last exchange in phase 1
and all exchanges in phase 2. - Establishes a pair of cookies to keep different
sessions different.
49IPSec IKE
- Phase 1 protocols
- Read them!
50IPSec IKE
- Phase 2 A.k.a. quick mode.
- Uses a pair X of cookies generated in phase 1.
- Session nonce for phase 2 session.
- All messages are encrypted with Phase 1
encryption key SKEYID_e - All messages are integrity protected with Phase 1
intergrity key SKEYID_a. - Can be initiated by either participant of Phase 1.
51IPSec IKE
X,Y, Crypto-protocol, SPIA, nonceA,
Alice
Bob
X,Y, Crypto-protocol accepted, SPIB, nonceB
X, Y Ack
SPI Security Parameter Index
52Secure Socket Layer
- 1995 deployed in Netscape Navigator as SSLv2.
- 1995 Microsoft fixes SSLv2 and introduces a
similar protocol - Private Communication Technology (PCT)
- 1996 Netscape introduces SSLv3
- 1999 IETF introduces Transport Layer Security.
- SSLv3 remains the most implemented protocol.
53Secure Socket Layer
- SSL is built on top of TCP.
- TCP provides reliable packet delivery.
- Rogue packet problem
- Maliciously introduced TCP packet.
- Easy to do, since it only needs to satisfy the
non-cryptographic TCP checksum. - SSL disregards the package.
- TCP however will not accept the true packet,
because it looks like a double to it. - SSL will have to start over.
54Secure Socket Layer
- Various keys are formed from various random
numbers exchanged during the protocol. - Negotiate crypto-protocols.
55Secure Socket Layer
- SSL sessions are long-lived.
- Many SSL connections can be derived from an SSL
session.
56Secure Socket LayerSession Connection
Alice specifies lists of ciphers and a random
number
Bob gives certificate of his public key. Bob
picks cipher.
Hello. Ciphers I support. RAlice
Alice
Bob
Certificate. Ciphers I choose. RBob
Alice calculates the pre-master secret and sends
it to Bob, protected by Bobs public key. She
also creates a (complicated) hash of the
hand-shake message. She also calculates a session
key K
Bob responds with his version of the hash of the
session key.
SPublic Key of Bob. Keyed Hash of Messages
Keyed Hash of Messages
S is a random number, the pre-master secret.
Chosen by Alice. K is the master secret,
calculated from RAlice, RBob, S Bob has
authenticated himself to Alice, but not vice
versa!
57Secure Socket LayerSession Resumption
- If Bob wants to have multiple connections per
session, he sends in Message 2 a session id. - If Alice presents in Message 1 a session id, they
skip the handshake. - Alice can still negotiate ciphers with Bob who
might have changed policies.
Session ID. Ciphers I support. RAlice
Alice
Bob
Session ID. Certificate. Ciphers I choose. RBob
Keyed Hash of Messages
58Secure Socket LayerSession Resumption
- Session resumption is not stateless.
- Server Bob needs to maintain a database entry of
session id and master secret.
59Secure Socket Layer
- SSL comes deployed with public keys of various
trusted organizations. - User can modify this list.
- User verifies public keys by sending certificate
requests to the organizations in the list.
60Secure Socket Layer
- SSLv3 upgrades
- Protects against the downgrade attack
- Active attacker replaces the initial messages
with ones containing weak crypto. - Protects against the truncation attack
- Active attacker sends a TCP close (FIN) message.
- TCP is not protected, so the connection is
abnormally terminated without SSL being aware of
it.
61Secure Shell SSH
- SSH client and server are applications (running
on top of OS). - SSH consists of a bunch of applications.
- But SSH is not a UNIX shell.
62Secure Shell SSH
- Provides
- Authentication
- Encryption
- Integrity
63Secure Shell SSH
- SSH provides
- scp secure file transfer
- Secure remote command execution
- Automatic authentication
- Place public key files on remote computers
- Enable SSH clients (scp, ssh) to access remote
accounts - Invoke ssh-agent program
- Choose keys needed for remote logins.
- Load private keys with ssh-add (invoking
passphrase) - ssh-agent keeps private keys in memory.
- Delegate limited authentication.
- Secretary can only read the email.
- Port forwarding
64Secure Shell SSH1
- Client contacts server.
- By going to port 22 by convention.
- Client and server disclose the SSH versions they
support. - Client and server switch to a packet based
protocol. - Packet consists of
- 4B length,
- 1-8B of random padding,
- one-byte packet type code,
- packet payload data,
- four-byte integrity check field.
65Secure Shell SSH1
- Server identifies itself by sending
- Host key
- Server key
- 8 random bytes (use as cookie)
- List of encryption, compression, authentication
methods. - Both sides compute a 128b session identifier.
66Secure Shell SSH
- When the client receives the host key, the client
looks into the known host database. - If the host key matches the one in the database
then the client proceeds. - If the host is in the database but with a
different key, then the client queries the user. - Otherwise, the client warns the user and proposes
to add host and key to the known host database.
67Secure Shell SSH
- Client randomly generates a session key.
- Clients sends the session key encrypted with the
server key and then with the hosts public key. - Together with the choice of crypto-suites.
- Both sides now use the session key for
encryption. - Server sends confirmation message encrypted with
the session key. - This proves the servers authenticity to the
client.
68Secure Shell SSH
- Authentication phase starts
- SSH1 tries out
- Kerberos
- Rhosts
- RhostsRSA
- Public key
- TIS
- Password
69Secure Shell SSH
- At this point, a secure communication channel has
been established. - Client is sure of the authenticity of server.
- Server now authenticates the client.
70Secure Shell SSH
- SSH2 changes
- SSH2 consists of modules
- SSH Transport layer protocol
- SSH Authentication protocol
- SSH Connection protocol
- SSH2 allows for additional parameter negotiation
- More general session key exchange possibilities
71Secure Shell SSH
- SSH-2 changes
- SSH-2 uses better integrity checking for
messages. - Supports password changes.
- User-authentication methods more restricted
- Public key (DSA, RSA, OpenPGP)
- Hostbased
- password