Introduction to Protocols:
Entity Authentication, Key Establishment,
Integrity/Message Authentication, Confidentiality
INFSCI 1075: Network Security – Spring 2013
Amir Masoumzadeh
Overview
Authentication
Weak entity authentication
Strong entity authentication
Authenticated Key Establishment
Key establishment and management
Public Key Infrastructure
Message Confidentiality/Privacy
Message Authentication








2
How Most Security Protocols Work?
Step 1: Alice verifies her “identity”
to Bob and vice-versa
Alice
Step 2: Alice and Bob establish a
shared “secret” (or a set of secrets)
Step 3: Data communications with
confidentiality and authentication
3
Bob
Authentication Schemes
Some typical scenarios requiring electronic “proof of
identity”


Withdrawing money from an automatic teller machine


Charging purchases to a credit card over telephones


4
Needs the credit-card number and expiration date
Remote login over a computer network


Needs a PIN number
Needs a login name and password
Authenticated key establishment protocols
Such Techniques Are NOT Secure in
General
Passive attacks


An eavesdropper can use the identifying information for his/her
own purposes
Credit card numbers and expiration dates are in
plaintext!
An ATM is somewhat more secure but someone
monitoring the communication line could obtain all the
information on the encoded strip as well as the PIN
number
Login and passwords are transmitted in plaintext (except
say with SSH)
Access to password files




5
What is User Authentication?
Message authentication


Involves a message and its integrity as well as where it originated
(later)
User authentication


There is NO meaningful message





Only a claim that “This is me”
It is real-time
Basis of access control & user accountability
Also called “identity verification”
Has two steps


identification - specify identifier
verification - bind entity (person) and identifier
Formal Definition: Authentication is the procedure by which
one party is assured of the identity of a second party involved
in a protocol through corroborative evidence

6
Objectives of Authentication
In the case of honest parties Alice and Bob, Alice should
be successfully able to authenticate herself to Bob
Bob should not be able to use the identification exchange
with Alice to compromise her
Oscar should not be able to impersonate Alice in an
exchange with Bob, even though he is able to observe a
large number of previous identification exchanges
between Alice and Bob
The above hold even if






7
Oscar has successfully participated in an authentication scheme
with Alice and/or Bob
Oscar can simultaneously start multiple instances of the entity
authentication protocol
Means of User Authentication
What you know


Something known by the party to be authenticated: PIN,
Password, etc.
What you have


Something the party to be authenticated possesses: Smart card
with a time variant password
What you are or you do


Something inherent to the party to be authenticated:
Biometrics like fingerprints, voice, retinal patterns, etc.
Comments:



8
Authentication can be mutual or one way
It should be computationally efficient
Weak Entity Authentication
Features:



Uses a fixed or time-invariant password, pin, or some other
quantity
The password or pin is shared between the user and the
system



Secret key scheme
The User ID is the claim of identity
The Password is the evidence in support of the claim
Verification



9
The user supplies the password to the system (reveals the
password!)
The system accepts this as a corroboration of the user’s
identity
Storing Passwords

Obvious approach





Store passwords in plaintext
Set read and write access controls
Superusers can determine the password
If Oscar gets superuser access, the passwords are easily available
“Encrypted” password files



Password is stored as a hash value or encrypted value
To verify identity, the system computes the hash of the supplied
password and compares the entry in the stored file
It is called “encrypted” even though most times it is a hash value that is
stored
* A hash function is any well-defined procedure or mathematical
function that converts a large, possibly variable-sized amount of data
into a small datum, usually a single integer that may serve as an index
to an array
10
Attacks against Fixed Passwords

Replay of fixed passwords



Exhaustive password search




People write down passwords
If transmitted in plaintext (like telnet), Oscar can capture it on the
link
Oscar keeps trying each possible password
Online attacks are rare (e.g., locks up after three trials)
Offline attacks are more serious
Password guessing and dictionary attacks



11
Given access to a password file (encrypted), Oscar tests each
password to see if there is a match
Easy to do since the hash function is known
To improve the probability of success, Oscar tries common words,
proper names, lowercase strings etc. – dictionary attacks
Preventive Measures

Password rules


Require users to have special characters, capital letters, etc. in
their password
Entropy = uncertainty in password



Make the password verification process slow



Try to ensure that all passwords are equally likely
Makes attacks more difficult
Verifying a few passwords is easy
Comparing millions of passwords may be very time consuming
Use pass phrases


12
Increases the entropy without reducing human ability to
remember
Passphrases are stored as hash values and NOT truncated
Preventive Measures (cont.)

Salting





Augment passwords by a random string of t-bits before applying the
hash function
The hash value and the salt are both stored
This increases the effort of a dictionary attack (by how much?) but
not an exhaustive search
Used in the UNIX operating system
One-time passwords


Major security threat is eavesdropping and replay
Each password is used only once to prevent this problem


13
System and user share a sequence of t passwords that are used one after
the other
Sequentially updated – during authentication, the user and system
exchange the password to be used the next time
Challenge-Response or Strong Entity
Authentication




Idea: Alice proves her identity to Bob by demonstrating
“knowledge” of a secret known to be associated with her
rather than revealing the secret itself to Bob during the
protocol
Use a Nonce* or some other time varying quantity as a
challenge
Use knowledge of the “secret” and the nonce in the response
Oscar, who is monitoring the communications medium gains
no useful information
* Nonce: a number or bit string used only once, in security
engineering
14
Nonce


A nonce is a quantity that is not used for the same purpose
more than once
Examples:





Sequence numbers
Time stamps
Random numbers
Concatenation of a combination of these
Typically serves to prevent otherwise undetectable replay
15
Challenge-Response Protocol Based on
Shared Secret Keys
Alice
Shared secret key kAB
Bob
Generate a challenge x
x
Compute y = fkAB(x)
y
Compute y* = fkAB(x)
Compare y* and y
16
Example

Examples of functions


DES encryption
Computing xkAB mod p


Used in smart cards and pass-code generators
Secret Key kAB= 7; p = 17
Alice
Compute
37 mod 17 = 11
17
Challenge = 3
Bob
Response = 11
Check response
Assumptions of previous protocol



Alice and Bob share a secret key
The authentication protocol is unilateral
The claim of identity is presumably completed earlier
to the C-R protocol


Possibly in cleartext
Modified version of this protocol is specified in the
ISO/IEC 9798-2 standard
18
Session Hijacking



Alice identifies herself to Bob using a C-R protocol
After the C-R protocol, Oscar may interject himself by spoofing
Alice’s address
 This is called session hijacking
How do we prevent session hijacking?
 A secret key MUST be exchanged as part of the
identification/authentication
 The secret key can be used to prevent spurious messages from
being sent with the same address (how?)
19
The “Key” Problems
Two communicating parties must share a secret key
The keys should change frequently to prevent Oscar from
getting too much of information about it




The more ciphertext Oscar can have, the better the attack
The more often you use the key, the better the attack
Solution: use a hierarchy of keys

20
Authenticated Key Establishment (AKE)

Establish a secret key with an entity whose identity has been
verified


Also called Authentication and Key Agreement (AKA) in some
specific protocols
Used in many applications




21
Dial-up systems
Kerberos
802.11i (WLANs)
Cellular telephony
Key Establishment & Management

Key Establishment




A “secure” process by which a shared secret key becomes
available to two or more parties for use later on for
encryption, authentication, etc.
Result of the protocol is the creation of a shared secret
“session key”
The session key is restricted for use for only a short time after
which it is obliterated
Key Management

22
Set of processes and mechanisms which support key
establishment and maintenance of ongoing “key” relationships
such as replacing older keys, updating keys, storing keys, the
roles of trusted third parties, etc.
Key Establishment

Key Distribution or Transport



Key Agreement



One party chooses the secret key
The secret key is securely
transported to the other parties
Sometimes we make use of a
Trusted Authority (TA), a Trusted
Third party (TTP) or a Key
Distribution Center (KDC)
23
Key
Two or more parties jointly establish
Establishment
a secret key by communicating over a
public channel
Key
Key
e.g., Diffie-Hellman Key Exchange
Distribution
Agreement
Key Distribution Using Secret Keys

Session Keys




Used to encrypt communication between two end systems
Used only for the duration of the logical connection (or for a
fixed duration)
Transported to communicating entities using a “master key”
Master Key




24
The key used for transporting session keys
It is considered to be a long-term key
Shared between communicating end-systems
Usually it is physically delivered or manually installed
Why Session Keys?

Limiting the availability of ciphertext


Limiting exposure


If the key is compromised, only the data that has used the
particular session key is compromised
Avoiding long term storage of a number of keys


The more the ciphertext, the more feasible the attack
If Alice needs to communicate with N possible users, she will
use a session key only when the need arises
Independence across communication sessions and
applications

25
Reduces the need to maintain state across sessions
Decentralized Key Distribution
(1) Req||N1
Bob
Alice
(2) ekAB(ks||Req||IDBob||f(N1)||N2)
Challenge
(3) eks(f(N2))
Response
26
• kAB is the Master Key
• ks is the Session Key
Drawbacks




A master key needs to be shared between all the nodes
that need to communicate
If there are N hosts we need N(N – 1)/2 keys
If we add a node to the network, all the other nodes
must now create a shared master key with it
Physical distribution of pairs of master keys is hard
27
Trusted Third Party

Use a Trusted Third Party (TTP) often called a Key
Distribution Center (KDC)



Each node or user shares a secret master key with the KDC
A session key is generated by the KDC each time two nodes
wish to communicate



This is a server based key distribution
If Alice or Bob generate the session key, we call this a “Key
Translation Center” or KTC
Can also be used for distributing public keys and associated
certificates - PKI later
Drawbacks:


28
The TTP must be trusted to keep the master keys secret
The TTP may be a bottleneck for providing the session keys
Key Exchange Using Public Keys

Why public keys?


We do not wish to trust a third party
Communications are created between entities that do not
know each other a priori



Example: Diffie-Hellman Key Exchange Protocol
RSA for key exchange
Problem: Man-in-the-Middle Attack
29
Key Exchange Using Public Keys
(1) Request
Alice
(2) IDB|| KUB
(3) eKUB(IDA||ks)
30
Bob
Man-In-The-Middle Attack
(1) Request
Alice
(1) Request
(2) Request
(3) IDB||KUB
(4) IDB||KUO
(5) eKUO(ks||IDA)
(6) eKUB(ks||IDA)
Oscar
y = eks(x)
31
Bob
Man-In-The-Middle Attack (cont.)

Transmitting a session key by encrypting it with a public key is
secure against “passive attacks”




It is NOT secure against ACTIVE attacks
Oscar can read and alter x without detection
Public keys are not authenticated (so far)
Applies also to the Diffie-Hellman Key Exchange Protocol
32
Distribution of Public Keys

Public Announcement




No authentication
Easy to masquerade
Example: PGP
Publicly available Directory







33
A TTP maintains an authenticated directory of names and associated
public keys
Each user registers his/her public key with the directory authority
Keys can be updated
Directories can be published periodically
Authenticated communication is possible via MACs to access the
directory electronically
Records may be tampered
Accessing the directory server could be a bottleneck
Using a Local Public Key Authority
(4) Req||Time2
(1) Req||Time1
PK Auth
(5) eKRAuth(KUA||Req||Time2)
Alice
(2) eKRAuth(KUB||Req||Time1)
(3) eKUb(IDA||N1)
(6) eKUa(N1||N2)
(7) eKUb(N2)
34
Bob
Using Public-Key Authority




Provides stronger encryption
The first four messages can be used infrequently to check
if the public keys have changed
Records might be manipulated at source (need third party
trust)
Bottleneck at the Authority
35
Public Key Certificates

Idea:



Keep everything autonomous




Bind the user’s identity to his public key via his SSN, name, etc.
Have a trusted authority to “certify” the binding
Anyone should be able to read the certificate
Anyone should be able to verify the authenticity and currency
of the certificate
No one should be able to create a certificate except the
trusted authority
How?

36
Use Digital Signatures
Requirements




Anyone should be able to read a certificate to
determine the identity and public key of the user
The certificate must be tamperproof
Only the Certificate Authority (CA) can change or
update a certificate
The certificate should have a verifiable lifetime
37
General Structure

The User needs




Identity: SSN, DOB, Name, E-mail address, URL etc.
Private Key KRU
Public Key KUU
The certificate authority needs


A secret signature algorithm sigKRAuth(x)
A public verification algorithm verKUAuth(y)
ID(User)
KU(User)
sigKRauth
(IDU||KUU)
38
Public Key Distribution Using Certificates
(4)IDB||KUB
(1) IDA||KUA
CA
Alice
(5) C(B) = ?
(2) C(A) = sigKRAuth(T1||IDA||KUA)
Bob
(3) C(A)
(6) C(B)
Alice can decrypt C(B)
Bob can decrypt C(A)
39
Oscar cannot generate a certificate
containing IDA||KUo or IDB||KUo
Advantages

There is no serious bottleneck since certificates rest with
the users and are “public”


They cannot be forged and can be placed in public
directories


They can be downloaded and kept offline before an actual
communication
Hierarchical certification and directories can be used
Certificates can be used for the validity of the lifetime
40
Certificate Example
41
Public Key Infrastructure (PKI)


Components that are necessary to securely distribute
public keys
Ideally consists of




42
Certificates
A repository for retrieving certificates
A method for revoking certificates
A method of evaluating a chain of certificates from public keys
that are known and trusted in advance of the target public key
Message Confidentiality/Privacy

Protection of transmitted data from unauthorized access


Clearly, the solution is encryption


Interception & release of information
If the data is encrypted (say using a block cipher in an
appropriate mode of operation) the contents are quite secure
Traffic analysis



43
Frequency of packets and dependence on time
Source and destination networks
Much harder to prevent
Traffic Confidentiality

Attack





Identification of communicating parties
Frequency of communication
Message pattern (length, quantity, etc.)
Event correlation
Security measures




44
Link encryption
Traffic padding
Pad data units to be of fixed size
Insert null messages
Message Authentication

Authentication



Integrity


Assurance that a message is coming from an entity that supposedly sent
it
Protection against masquerade or fraud
Assurance that the message has not been modified
 Contents – insertion, deletion, transposition, etc.
 Sequence – insertion, deletion, reordering
 Timing – delay or replay
Message Authentication = Authentication + Integrity
45
Message Authentication



How do we know whether or not a message is coming from
the “claimed” source?
How do we know that the message has not been modified in
between?
There must be an “authenticator” to verify the authenticity of
the message



46
Message encryption
Hash functions
Message authentication code
Secret Key Based Encryption for Message
Authentication
Alice
x
Encrypt
Insecure channel
y
k

k
Alice and Bob share a key k


Decrypt
Bob
x
Nobody else is aware of the key k
If a message is received by Bob that can be decrypted using
the key k, the message MUST have originated at Alice
47
Drawbacks of Simple Encryption for
Message Authentication


If the ciphertext y can be anything (e.g. a block of 64 bits
that look random), Oscar can send spurious or
meaningless messages to Bob
Bob cannot automatically say whether Alice sent the
meaningless messages



Need some structure in the plaintext that can be used to
determine spurious messages
The structure MUST be secure
Oscar can “replay” the messages sent by Alice without
being detected

48
We look at this later
General Idea of Using a “Function”
for Message Authentication

Generate a function or fingerprint of the message



Store it securely if the data is in an insecure place
Transmit it securely if the data is transmitted over an insecure
channel
If the data gets altered


49
Hopefully the altered data will NOT have the same fingerprint
as the original data
If the fingerprint is secure, we can detect the modification
A Simple Method for Securing the
Fingerprint




Append it to the message
Encrypt the message and the appended function
A random sequence of bits will not have the properties that
the above ciphertext has
Advantages

50
Using layered communications protocols automatically creates a form of
authentication because of the structure
General Idea for Message Authentication
Y = ek(x || f(x))
Alice
x
f(x)
e
d
k
k
x
x
f(x)
f
f
Bob
Compare
x || f(x)
51
How to Generate auth(x) ?

Use Hash Functions



Takes as input a binary string of arbitrary length
Creates as output a fingerprint of this string
The fingerprint is also called “message digest”



Typically a very short string
Important in the use of digital signatures
Use Message Authentication Codes (MAC) or Keyed
Hash Functions



52
The hash function is dependent on a shared secret key
between Alice and Bob
No need for securely keeping the fingerprint
Also called an “authentication tag”
Message Authentication without Privacy

In some applications, it is only necessary to authenticate
but not keep the information secret





Broadcast messages and alarm signals
Load on receiving side
Plaintext messages like shareware etc.
SNMPv3 and network management messages
Since the plaintext is sent without encryption, there is a
need to now add a secure authenticator to the message




53
The function auth(x) should be dependent on the message
It should not be easily created given the message
It should not be easily modified given the message
Computational security
Example 1
Alice
x
x
Ck(x)
C
k
54
x
x || Ck(x)
Ck(x)
k
C
Bob
Compare
Example 2
y= ek1(x || Ck(x))
x
e
d
Alice
x
Ck(x)
k1
C
Ck(x)
k
C
Bob
k
Compare
x || Ck(x)
55
k1
x
Example 3
Alice
x
x
x || ek(h(x))
h
ek(h(x))
h(x)
e
k
Similar to a MAC
Hash function is cryptographically protected
56
k
x
ek(h(x))
d
h
Bob
Compare
Example 4
Alice
x
x
x || (h(s||x))
h(s||x)
s
h
s
h(s||x)
h
Compare
Alice and Bob share a secret s
Similar to HMAC
Hash function must be one way to prevent s being discovered
57
x
Bob
Example 5
y = ek(x || h(x))
Alice
x
h(x)
e
d
k
k
h
x
h(x)
x
h
Bob
Compare
x || h(x)
58
Example 6
y = ek(x || h(x||s))
Alice
x
e
h(s||x)
s
k
h
d
x
s
k
h(s||x)
h
x || (h(x||s))
Compare
59
x
Bob