Cryptography
Module III
K. Salah
1
Security Services
 Confidentiality/Privacy
 Has to do with hiding information. Only the intended receiver can make
sense out of the message.
 Message Authentication
 Data Origin
 Can it be achieved by symmetric cipher? Yes
 Can it be achieved by asymmetric cipher? No
 Data Integrity
 Can it be achieved by symmetric cipher? (not really)
 Can it be achieved by asymmetric cipher? (not really)
 There is that possibility that bits (cipher bit-block) can be re-ordered in transit
 Non-Repudiation
 The receiver must proof that the message came from a specific sender.
 The sender can not repudiate/deny sending the message
K. Salah
2
Digital Signature – signing whole document
K. Salah
3
Digital Signature – signing the digest
K. Salah
4
Digital Signature
Provides
Authentication
Data Origin
Data Integrity (with free-collision hashing)
Nonrepudiation
Does not provide confidentiality/privacy
Need to encrypt the message
K. Salah
5
What is the difference (in terms of nonrepudiation, data origin, data integrity,
confidentiality) when:
Sign then Encrypt
Encrypt then Sign
Sign and encrypt only PT message
K. Salah
6
MIM Attack and ARP
Poisoning
with a demo
K. Salah
7
User Authentication
 User Authentication =
Verification of identity
 Secret key approach
 Using Symmetric-Key only
 MIM attack where data is
intercepted, tampered
with, or replayed again to
receiver
 Using a nonce/challenge
 A random number
 Replay is resolved
 Bidirectional
 Must have a unique
challenge per sessions
 Public key approach
 Subject to MIM attack
K. Salah
8
Key Management
Symmetric Key Distribution
Problems with distributing symmetric key
Diffe-Hellman Method
Subject to MIM attack
KDC Method
Public-Key Certification
Certificate-based
K. Salah
9
Diffe-Hellman Method
K. Salah
10
MIM Attack
K. Salah
11
KDC (Key Distribution Center)
Problem with Diffe-Hellman approach is
that information is sent in plaintext
R1 and R2 needs to encrypted
A secret key is needed
So we have a vicious circuit
Three solutions
Using KDC
Needham-Schroeder Protocol
Otway-Rees Protocol
K. Salah
12
Using KDC



Sender and receiver registers with KDC and each given a private key
KDC sends a ticket back to sender
Vulnerable to replay attacks at step 3 and beyond
K. Salah
13
Needham-Schroeder Protocol



Solve replay attack
Uses 4 nonces
(R1-1) and (R2-1) are used to ensure that ticket was received correctly (decrypted and
processed properly)
K. Salah
14
Otway-Rees Protocol


Solve replay attack with fewer steps
R is a common nonce. R is different for each session. Used to make sure encryption and
decryption got processed properly
K. Salah
15
Public Key Certification
 MIM attack. Intruder can intercept the public key in
transit and send his own.
 A need for a trusted entity, a certificate authority (CA) to
solve public key fraud
 CA can be public.
 Their public key is trusted and embedded with the OS and
Applications. Also it can be added manually.
 Examples
 Thawte
 veriSign
 Entrust
 CA can be private
 Owned by an organization
K. Salah
16
X.509
Field
Explanation
Version
Version number of X.509
Serial number
The unique identifier used by the CA
Signature
The certificate signature, SHA-1, MD5 of CA
Issuer
The name of the CA defined by X.509
Validity period
Start and end period that certificate is valid
Subject name
The entity whose public key is being certified
Public key
The subject public key and the algorithms that use it
K. Salah
17
PKI (Public Key Infrastructure)




Like DNS, there is a need for hierarchical structure of CAs that are public and private
The principle of cross certification
The CA does not to be on-line
CA certificate is typically issued by upper level certificate.
 Root CA issues its own certificate
 Local CA can issue its own certificate
K. Salah
18
Use of Certificates
 Email
 PGP-based:
 Faster than S/MIME
 PGP, OpenPGP, GnuPG (Gnu Privacy Guard)
 Email clients:
•
•
•
Enigmail
PGP Mail
Hushmail (web based)
 S/MIME or Certificate based (Digitally signed and then encrypted)
 Email Clients:
•
•




Outlook
Mozilla Thunderbird
https and SSL
SSH
Software protection and signing
User authentication through certificate-based




FTP
Dialup
Directory
.Net
K. Salah
19
PGP
 Invented by Phil
Zimmermann to provide
privacy, integrity,
authentication, and
nonrepudiation
 Uses digital signature to
provide integrity,
authentication, and
nonrepudiation
 Uses one-time secret-key
and public-key encryption
to provide privacy
 Message only makes
sense at the receiver
 What is the job of one-time
secret key? What if it gets
removed?
 Encryption is faster with
one-time secret key,
especially when email is
long.
 One-time key is very
short
K. Salah
20
S/MIME




Secure / Multipurpose Internet Mail
Extension
provides similar services to PGP
based on technology from RSA Security
Can use symmetric or asymmetric key
encryption
 As specified in the MIME headers


S/MIME certificates are X.509 conformant
Contained in email clients





MS outlook
Netscape communicator
Eudora
Mozilla Thunderbird
etc
K. Salah
21
OpenSSL vs. PGP
 http://www.openssl.org
 OpenSSL is a cryptography toolkit implementing the Secure Sockets
Layer (SSL v2/v3) and Transport Layer Security (TLS v1) network
protocols and related cryptography standards required by them.
 The openssl program is a command line tool for using the various
cryptography functions of OpenSSL's crypto library from the shell. It
can be used for
 Creation of RSA, DH and DSA key parameters
 Creation of X.509 certificates, CSRs and CRLs
 CSR (Certificate Signing Request) containing public key to submit to CA
 CRL (Certificate Revocation List) to submit to CA to revoke certificates




Calculation of Message Digests
Encryption and Decryption with Ciphers
SSL/TLS Client and Server Tests
Handling of S/MIME signed or encrypted mail
K. Salah
22
Security facilities in the TCP/IP protocol
stack
K. Salah
23
SSL and TLS
 SSL – Secure Socket Layer
 TLS – Transport Layer Security
 Both provide a secure transport connection between
applications (e.g., a web server and a browser)
 SSL was originated by Netscape
 SSLv1 and SSLv2
 SSL version 3.0 has been implemented in many web
browsers (e.g., Netscape Navigator and MS Internet
Explorer) and web servers and widely used on the
Internet
 SSL v3.0 was specified in an Internet Draft (1996)
 It evolved into TLS specified in RFC 2246
 TLS can be viewed as SSL v3.1
K. Salah
24
Transport Layer Security





For any TCP protocol: HTTP (https:// port 443), NNTP,
telnet, POP, SFTP, etc.
For transactions on Internet, a browser needs:
 Make sure that server belongs to the actual vendor
 Contents of message are not modified during
transition
 Make sure that the impostor does not interpret
sensitive information.
TLS has two protocols: Handshake and data exchange
protocol.
Handshake: Responsible for negotiating security
parameters (encryption method, etc), authenticating the
server to the browser, and (optionally) defining other
communication parameters.
Data exchange (record) protocol uses the secret key to
encrypt the data for secrecy and to encrypt the message
digest for integrity.
K. Salah
25
SSL Record Protocol Services
Confidentiality – the handshake protocol
defines a shared key for encryptions of
SSL payloads
Message Integrity – the handshake
protocol defines a shared key used to form
message authentication code (MAC)
K. Salah
26
SSL Record Protocol Operation
K. Salah
27
SSL Architecture
K. Salah
28
Handshake Protocol





Browser sends a hello message that includes TLS version
and some preferences
Server sends a certificate message that includes the public
key of the server. The public key is certified by some
certification authority, which means that the public key is
encrypted by a CA private key. Browser has a list of CAs
and their public keys. It uses the corresponding key to
decrypt the certification and finds the server public key. This
also authenticates the server because the public key is
certified by the CA.
Browser sends a secret key, encrypts it with the server
public key, and sends it to the server.
Browser sends a message, encrypted by the secret key, to
inform the server that handshaking is terminating from the
browser key.
Server decrypts the secret key using its private key and
decrypts the message using the secret key. It then sends a
message, encrypted by the secret key, to inform the
browser that handshaking is terminating from the server
side.
K. Salah
29
SSL Hashing and Encryption
 supported hash functions:
 MD5
 SHA-1
 supported encryption algorithms
 block ciphers (in CBC mode)
 RC2_40
 DES_40
 DES_56
 3DES_168
 IDEA_128
 Fortezza_80
 stream ciphers
 RC4_40
 RC4_128
K. Salah
30
client_hello
server_hello
Phase 1: Negotiation of the session ID, key exchange
algorithm, MAC algorithm, encryption algorithm,
Compression, and exchange of initial random numbers
or nonces to prevent replay attacks of key exchange.
certificate
server_key_exchange
certificate_request
Phase 2: Server may send its certificate and key
exchange message, and it may request the client
to send a certificate. Server signals end of hello
phase.
server_hello_done
certificate
client_key_exchange
certificate_verify
Phase 3: Client sends certificate if requested and may
send an explicit certificate verification message.
Client always sends its key exchange message.
change_cipher_spec
finished
change_cipher_spec
Phase 4: Change cipher spec (to change the operating
state to finished) and finish handshake
finished
K. Salah
31
State changes

State






Handshake
Alert
Data Exchange
operating state
 currently used state
pending state
 state to be used
 built using the current state
operating state  pending state
 at the transmission and reception of a Change Cipher Spec message
party A
(client or server)
party B
(server or client)
the sending part of the
pending state is copied
into the sending part
of the operating state
the receiving part of the
pending state is copied
into the receiving part
of the operating state
K. Salah
32
Server certificate and key exchange
messages

certificate
 required for every key exchange method except for anonymous DH (Diffe-Hellman)
 contains one or a chain of X.509 certificates (up to a known root CA)
 may contain




public RSA key suitable for encryption, or
public RSA or DSS key suitable for signing only, or
fix DH parameters
server_key_exchange
 sent only if the certificate does not contain enough information to complete the key exchange (e.g., the
certificate contains an RSA signing key only)
 may contain



public RSA key (exponent and modulus), or
DH parameters (p, g, public DH value), or
Fortezza parameters
 digitally signed



certificate_request



if DSS (Digital Signature Standard by NIST): SHA-1 hash of (client_random | server_random | server_params) is signed
if RSA: MD5 hash and SHA-1 hash of (client_random | server_random | server_params) are concatenated and encrypted
with the private RSA key
sent if the client needs to authenticate itself
specifies which type of certificate is requested (rsa_sign, dss_sign, rsa_fixed_dh, dss_fixed_dh, …)
server_hello_done



sent to indicate that the server is finished its part of the key exchange
after sending this message the server waits for client response
the client should verify that the server provided a valid certificate and the server parameters are acceptable
K. Salah
33
Client authentication and key exchange

certificate
 sent only if requested by the server
 may contain



public RSA or DSS key suitable for signing only, or
fix DH parameters
client_key_exchange
 always sent (but it is empty if the key exchange method is fix DH)
 may contain




RSA encrypted pre-master secret, or
client one-time public DH value, or
Fortezza key exchange parameters
certificate_verify
 sent only if the client sent a certificate
 provides client authentication
 contains signed hash of all the previous handshake messages





if DSS: SHA-1 hash is signed
if RSA: MD5 and SHA-1 hash is concatenated and encrypted with the private key
MD5( master_secret | pad_2 | MD5( handshake_messages | master_secret | pad_1 ) )
SHA( master_secret | pad_2 | SHA( handshake_messages | master_secret | pad_1 ) )
finished




sent immediately after the change_cipher_spec message
first message that uses the newly negotiated algorithms, keys, IVs, etc.
used to verify that the key exchange and authentication was successful
contains the MD5 and SHA-1 hash of all the previous handshake messages:
MD5( master_secret | pad_2 | MD5( handshake_messages | sender | master_secret | pad_1 ) ) |
SHA( master_secret | pad_2 | SHA( handshake_messages | sender | master_secret | pad_1 ) )
where “sender” is a code that identifies that the sender is the client or the server (client: 0x434C4E54; server: 0x53525652)
K. Salah
34
Countermeasures to hijacking SSL
sessions using MIM attack
 Education
 Sysadmins
 Register with CA
 Users
 Beware of alerts
 Use L3 Switches
 Track and maintain IP/MAC pairs
 S-ARP protocol
 Certificate-based
 Modify kernel to not honor unsolicited ARP replies
 Sun Solaris
 Linux 2.4 and 2.6
 Use IDS
 Track and maintain IP/MAC pairs
K. Salah
35
Kerberos V5– not a certificate based authentication
 A network authentication protocol of users developed by MIT
 Name after Greek Mythology – a dog with 3 heads that guards the gates
 Used in Windows to overcome shortcomings of NTLM
 NTLM is less secure. Latest version uses a challenge/response authentication
 Client id itself to the Server
 Server sends the Client a challenge, R
 Client responds in one message with NT response and LM response
•
•
•
NT response is based on LM Hash (of user password) and R
LM response is based on NT Hash (of user password) and R
Therefore, one can crack LM Hash or NT Hash separately!
 This info is based on reverse engineering
 In Windows XP, either Kerberos or NTLM can be selected for user authentication
 Kerberos claims of more scalability and is more backward compatible.
 Has three servers
 Authentication Server (AS)
 Ticket-Granting Server (TGS)
 Real Server
 FTP server
 Dial up server
 Directory server
K. Salah
36
Kerberos Servers
K. Salah
37
Kerberos Example




KA is generated locally when AS replies the first time. Alice has to enter a password. The password is then destroyed.
T is a challenge or a Timestamp to prevent replay attack
KS is the session key
If Alice wants to communicate to anther server, she does not to do the first two steps again
K. Salah
38

Kerberos on youtube

http://www.youtube.com/watch?v=7-LjpO2nTJo
K. Salah
39