ClientServer ClientID, E(x, CHK) E(x+1, SHK), E(y, SHK) E(y+1, CHK) E(SK, SHK) Three-way handshake Authentication Protocols CHK, SHK are keys known by both sides When this message is received by the server, the identity of the client is not known At this point the client knows the identity of the server since it decrypted x At this point the server knows the client because it was able to decrypt y A new session key is exchanged so CHK and SHK aren’t as vulnerable to attacks

Three Way Handshake Assumes both sides know CHK and SHK This could correspond to a password We still need a way to distribute keys assuming the client and server share no keys

Kerberos Trusted third party (Kerberos) AS B E((A,T),K), E((T,L,K,A),K B ) E((T,L,K,A),K B ) E(T+1,K) E((T,L,K,B),K A ), A, B S shares K A with A, but B does not know K A, A does not know K B A Asks S for a key to communicate with B S responds encoding the session key K and timestamp T and length of time to expire L A can’t decrypt the second message A proves it knows the encryption key K Forwarded from S B Proves it was able to decrypt message from S

Kerberos K is used like a DES session Key Key exchange depends on a trusted 3 rd party

AB B E(x, Public ) x Public key authentication

RSA Public key encryption Each user has a public and a private key The public encryption key is a pair (e,n) The private key is a pair (d,n) e, d and n are all positive integers The pair (e,n) is publicly known and can be accessed by anyone for encryption or decryption

Algorithm stage 1 1) Choose 2 prime numbers, p & q  p=47,q=59 2) n = p * q  n = ) L(n) = (p-1) * (q-1)  L(n) = ) Find a value d such that d > p, d > q & the greatest common divisor of d and L(n) is 1 - choose d = 157 5) Calculate e such that: e * d MOD L(n) = 1  e = 17

Algorithm stage 2 The encryption algorithm is: E(m) = m e MOD n = C - public or E(m) = m d MOD n = C - private The decryption algorithm is: D(C) = C d MOD n - private or D(C) = C e MOD n - public

RSA Example From previous: d = 157, e = 17, n = 2773 Let the message be: it is all greek to me Encode: space = 00, a = 01, b = 02, etc. Blocked (2 letters at a time) Encrypted M e mod n = mod 2773 = etc.

Public and private keys Encryption and decryption can go either way we can encrypt with either the public key or the private key Example (client verification): a server wants to be sure that a message came from a particular client it knows the client’s public key if the client encrypts the message with its private key, then the server can only decrypt it with the same client’s public key

Digital signatures We can also ensure that a message can only be passed between a particular client and a particular server: The client encrypts the message using its private key, then again using the server’s public key It then sends the message to the server Only that server can decrypt the message using its private key, then the client’s public key Message: Mission accomplished 007’s private key E M’s public key E 007’s public key D M’s private key D network

Credits RSA Lecture by Quinn Snell & Peter Biggs 2000 James Bond Images © Eon Productions James Bond Logos © Danjaq James Bond Theme written by Monty Norman and © Eon Productions All rights reserved Some of the information in this lecture is based on the United Artists Corporation/Eon Productions/Danjaq Inc. movies. All the movies and the pictures and sounds taken from them are copyrighted to their respective companies. This information is for viewing and personal interest only. Any use of this information for commercial gain is strictly prohibited.

Session Keys Data over the net should be encrypted Both sides must agree on encryption key(s) The key that is used for the connection is called the session key Generally DES key We must protect the session key

Protecting the session key Most security systems send the session key over the network Kerberos Encrypted by users password and server secret keys SSH Encrypted by host keys Can we agree on the session key without sending it over the network?

Diffie-Hellman Key Agreement Allows two hosts to come to agreement about a secret key without sending the key over the network Based on the difficulty of factoring large primes

Diffie-Hellman Key Agreement Hosts must initially agree on p and g p is a prime number g is a number less than p Each host generates a random number x Each host calculates y = g x mod p Hosts exchange their y values Each host calculates z = y x mod p Both hosts now have the same value

Diffie-Hellman Key Agreement Hosts must initially agree on p and g –p = 1113 –g = 911 Each host generates a random number 7 and 63 & 7 Each host calculates y = g x mod p = 9 7 mod 11 = mod 13 = 5 y = g x mod p = 9 6 mod 11 = mod 13 = 2 Hosts exchange their y values Each host calculates z = y x mod p = 9 7 mod 11 = 42 3 mod 13 = 8 z = y x mod p = 4 6 mod 11 = 45 7 mod 13 = 8

Diffie-Hellman Key Agreement How does it work? Each host calculates y1 = g x1 mod p y2 = g x2 mod p They exchange and calculate z = y2 x1 mod p z = y1 x2 mod p Which is equivalent to z = (g x2 mod p) x1 mod pz = (g x1 mod p) x2 mod p z = g x2x1 mod pz = g x1x2 mod p

Diffie-Hellman Key Agreement Why can’t it be broken? We can capture both y values Each y value is then raised to a different power to calculate the key We would have to factor each of the y values to get x1 and x2 Discrete logarithm

Keyed MD5 Sender and receiver share key k sender m + MD5(m + k) receiver applies MD5 to the concatenation of random key message compares result with checksum sent with message Man-in-the middle can not recompute MD5 because he doesn’t have secret key k

Keyed MD5 sender m + MD5(m + k) + E(k, private) receiver recovers random key using the sender's public key applies MD5 to the concatenation of this random key message compares result with checksum sent with message Man-in-the middle can intercept k, change message, change checksum, and the receiver wont know

Fixed Keyed MD5 Sender m + MD5(m + k) + E(E(k, r-public), s-private) receiver recovers random key using the sender's public key and receivers private key applies MD5 to the concatenation of this random key message compares result with checksum sent with message Authenticates sender Man-in-the middle can not intercept k because it is encrypted with the public key of the receiver Only works for one receiver

What about this? Sender m + MD5(m + k) + E(k, r-public) receiver recovers random key using the receivers private key applies MD5 to the concatenation of this random key message compares result with checksum sent with message Man-in-the middle can make up a new key and send it using the receivers public key

Another Keyed MD5 Sender m + E( MD5(m + k) + k, s-private) receiver recovers random key using the sender's public key applies MD5 to the concatenation of this random key message compares result with checksum sent with message Man-in-the middle can not change message because checksum is encrypted with the private key of the sender

MD5 with RSA signature sender m + E(MD5(m), s-private) receiver decrypts signature with sender's public key compares result with MD5 checksum sent with message

Certificates Certified Entity CA Verifier Decrypt senders public key using CA- publickey Albert Levi Albert Levi Register with CA, send client Public Key CA-Publickey and Certificate with RSA(client Public Key,CA-privatekey) Certificate

Hierarchical PKI Example RSA(UserPubK,CAPriK) RSA(CAPubK.UCAPriK) RSA(UCAPubK,RootCAPriK)

PEM Encryption Illustrated Decrypt message using DES with secret keyk DecryptE(k) using RSA with my private key ->k Convert ASCII message Encryptk using RSA with recipient’s public key Encode message +E(k) in ASCII for transmission Encrypt message using DES with secret keyk Create a random secret keykOriginal message Transmitted message

PEM message integrity and authentication Sender identity and message integrity confirmed if checksums match Calculate MD5 checksum on received message and compare against received value Decrypt signed checksum with sender’s public key Calculate MD5 checksum over message contents Sign checksum using RSA with sender’s private key Transmitted message m+E(MD5(m),private sender )

PEM Certificates User CA PCA1PCA2 IPRA PCA3 CA IPRA=Internet Policy Registration Authority (root) PCAn=policy certification authority CA=certification authority

TLS,SSL,HTTPS Transport Layer Security, Secure Socket Layer

SSL Each browser is configured with a root CA When a session is initiated, server and client agree on security capabilities. (most clients are 40 bit encryption, but 128 bit encryption is available on many strong servers The server is authenticated by the certificate authority Using the server public key from the CA, the client sends a DES key to the server The DES key is used to encrypt the session

IPSEC Optional in IPv4, mandatory in IPv6 Data Confidentiality---The IPSec sender can encrypt packets before transmitting them across a network. Data Integrity---The IPSec receiver can authenticate packets sent by the IPSec sender to ensure that the data has not been altered during transmission. Data Origin Authentication---The IPSec receiver can authenticate the source of the IPSec packets sent. This service is dependent upon the data integrity service. Anti-Replay---The IPSec receiver can detect and reject replayed packets.