AUTHENTICATION

AUTHENTICATION
Alice must prove her identity to Bob
 Alice and Bob can be humans or computers

May also require Bob to prove he’s Bob (mutual

authentication)
Probably need to establish a session key
May have other requirements, such as
 Use public keys
 Use symmetric keys
 Use hash functions
 Anonymity, plausible deniability, etc., etc.
AUTHENTICATION
Authentication on a stand-alone computer is relatively
simple
 What you know
 What you have
 What you are

Authentication over a network is challenging

 Attacker can passively observe messages
 Attacker can replay messages
 Active attacks possible (insert, delete, change)
AUTHENTICATION
What you know (password). Passwords can be cracked.
 Brute force attack
 Dictionary attack
 Hybrid
 Markov chain

Authentication using password only is challenging

 Cracking a Password Hash with John (JTR)
 https://www.youtube.com/watch?v=cPEMgt9lX2I
 Attacker can use online attack (slow): hydra
 https://tools.kali.org/password-attacks/hydra
 Attacker can use offline attack (fast): rainbow tables
 http://hackerwarehouse.com/product/rainbow-tables-hdd/
SIMPLE AUTHENTICATION
“I’m Alice”

Prove it

My password is “frank”

Alice Bob

Simple and may be OK for standalone system

But insecure for networked system
 Subject to a replay attack (next 2 slides)
 Also, Bob must know Alice’s password
AUTHENTICATION ATTACK
“I’m Alice”

Prove it

My password is “frank”

Alice Bob

Trudy
AUTHENTICATION ATTACK
“I’m Alice”

Prove it

My password is “frank”
Trudy Bob

This is an example of a replay attack

How can we prevent a replay?
 Timestamps
 Challenge/response
SIMPLE AUTHENTICATION

I’m Alice, my password is “frank”

Alice Bob

More efficient, but…

… same problem as previous version
BETTER AUTHENTICATION
“I’m Alice”

Prove it

h(Alice’s password)

Alice Bob

Better since it hides Alice’s password

 From both Bob and Trudy

But still subject to replay

CHALLENGE-RESPONSE
To prevent replay, use challenge-response
 Goal is to ensure “freshness”

Suppose Bob wants to authenticate Alice

 Challenge sent from Bob to Alice

Challenge is chosen so that…

 Replay is not possible
 Only Alice can provide the correct response
 Bob can verify the response
NONCE
To ensure freshness, can employ a nonce
 Nonce == number used once

What to use for nonces?

 That is, what is the challenge?

What should Alice do with the nonce?

 That is, how to compute the response?

How can Bob verify the response?

Should we rely on passwords or keys?
 CHALLENGE-RESPONSE
“I’m Alice”

Nonce

h(Alice’s password, Nonce)

Alice Bob
One-way Function:
 Nonce is the challenge Password of Alice cannot be
retrieved directly from the hashed
 The hash is the response value
 Nonce prevents replay, ensures freshness
 Password is something Alice knows
 Note: Bob must know Alice’s pwd to verify
GENERIC CHALLENGE-RESPONSE
“I’m Alice”

Nonce

Something that could only be

Alice from Alice (and Bob can verify) Bob

In practice, how to achieve this?

Hashed password works, but…
Encryption is better here (Why?)
AUTHENTICATION
WITH SYMMETRIC KEY
SYMMETRIC KEY NOTATION
Encrypt plaintext P with key K
C = E(P,K)
Decrypt ciphertext C with key K
P = D(C,K)
Here, we are concerned with attacks on protocols,
not attacks on crypto
 So, we assume crypto algorithms are secure
AUTHENTICATION: SYMMETRIC KEY
Alice and Bob share symmetric key K
Key K known only to Alice and Bob
Authenticate by proving knowledge of shared symmetric key
How to accomplish this?
 Cannot reveal key, must not allow replay (or other) attack, must be verifiable, …
 AUTHENTICATION WITH
SYMMETRIC KEY
“I’m Alice”

E(R,K)
Alice, K Bob, K

 Secure method for Bob to authenticate Alice

Alice does not authenticate Bob
 So, can we achieve mutual authentication?
MUTUAL AUTHENTICATION
“I’m Alice”, R

E(R,K)

E(R,K)
Alice, K Bob, K

What’s wrong with this picture?

“Alice” could be Trudy (or anybody else)!
MUTUAL AUTHENTICATION
Since we have a secure one-way authentication protocol…
The obvious thing to do is to use the protocol twice
 Once for Bob to authenticate Alice
 Once for Alice to authenticate Bob

This has got to work…

MUTUAL AUTHENTICATION
“I’m Alice”, RA

RB, E(RA, K)

E(RB, K)
Alice, K Bob, K

This provides mutual authentication…

…or does it? See the next slide
MUTUAL AUTHENTICATION ATTACK
1. “I’m Alice”, RA

2. RB, E(RA, K)

5. E(RB, K)
Trudy Bob, K

3. “I’m Alice”, RB

4. RC, E(RB, K)

Trudy Bob, K
MUTUAL AUTHENTICATION
Our one-way authentication protocol is not secure for
mutual authentication
 Protocols are subtle!
 The “obvious” thing may not be secure

Also, if assumptions or environment change, protocol

may not be secure
 This is a common source of security failure
 For example, Internet protocols
SYMMETRIC KEY MUTUAL
AUTHENTICATION
“I’m Alice”, RA

RB, E(“Bob”,RA,K)

E(“Alice”,RB,K)

Alice, K Bob, K

Do these “insignificant” changes help?

Yes!
AUTHENTICATION WITH
PUBLIC KEY
PUBLIC KEY NOTATION
Encrypt M with Alice’s public key: {M}Alice
Sign M with Alice’s private key: [M]Alice
Then
 [{M}Alice ]Alice = M
 {[M]Alice }Alice = M

Anybody can use Alice’s public key

Only Alice can use her private key
PUBLIC KEY AUTHENTICATION
“I’m Alice”

{R}Alice

Alice Bob

Is this secure?
Trudy can get Alice to decrypt anything!
 So, should have two key pairs
PUBLIC KEY AUTHENTICATION
“I’m Alice”

[R]Alice

Alice Bob

Is this secure?
Trudy can get Alice to sign anything!
 Same as previous  should have two key pairs
PUBLIC KEYS
Generally, a bad idea to use the same key pair for encryption and signing
Instead, should have…
 …one key pair for encryption/decryption…
 …and a different key pair for signing/verifying signatures
KEY DISTRIBUTION
SESSION KEY
Usually, a session key is required
 i.e., a symmetric key for a particular session
 Used for confidentiality and/or integrity

How to authenticate and establish a session key (i.e.,

shared symmetric key)?
 When authentication completed, want Alice and Bob to share a
session key
 Trudy cannot break the authentication…
 …and Trudy cannot determine the session key
SESSION KEY (CNTD.)
Session key (i.e., shared symmetric key) can be
established using
 Public-key crypto systems
 Symmetric-key crypto system !!
 Kerberos
KEY DISTRIBUTION USING
PUBLIC-KEY
AUTHENTICATION & SESSION
KEY
“I’m Alice”, R

{R,K}Alice

{R +1,K}Bob
Alice Bob

Is this secure?
 Alice is authenticated and session key is secure
 Alice’s “nonce”, R, useless to authenticate Bob
 The key K is acting as Bob’s nonce to Alice

No mutual authentication
PUBLIC KEY AUTHENTICATION
AND SESSION KEY
“I’m Alice”, R

[R,K]Bob

[R +1,K]Alice

Alice Bob

Is this secure?
 Mutual authentication (good), but…
 … session key is not secret (very bad)
PUBLIC KEY AUTHENTICATION
AND SESSION KEY
“I’m Alice”, R

{[R,K]Bob}Alice

{[R +1,K]Alice}Bob
Alice Bob

Is this secure?
Seems to be OK
Mutual authentication and session key!
PUBLIC KEY AUTHENTICATION
AND SESSION KEY
“I’m Alice”, R

[{R,K}Alice]Bob

[{R +1,K}Bob]Alice

Alice Bob

Is this secure?
Seems to be OK
 Anyone can see {R,K}Alice and {R +1,K}Bob
TIMESTAMPS
A timestamp T is derived from current time
Timestamps used in some security protocols
 Kerberos, for example

Timestamps reduce number of msgs (good)

 Like a nonce that both sides know in advance

Clocks never exactly the same, so must allow for clock

skew  creates risk of replay
 How much clock skew is enough?
PUBLIC KEY AUTHENTICATION
WITH TIMESTAMP T
“I’m Alice”, {[T, K]Alice}Bob

{[T +1, K]Bob}Alice

Alice Bob

 Secure mutual authentication?

 Session key?
 Seems to be OK
PUBLIC KEY AUTHENTICATION
WITH TIMESTAMP T
“I’m Alice”, [{T, K}Bob]Alice

[{T +1, K}Alice]Bob

Alice Bob

 Secure authentication and session key?

 Trudy can use Alice’s public key to find

{T, K}Bob and then…

PUBLIC KEY AUTHENTICATION
WITH TIMESTAMP T
“I’m Trudy”, [{T, K}Bob]Trudy

[{T +1, K}Trudy]Bob

Trudy Bob

 Trudy obtains Alice-Bob session key K

 Note: Trudy must act within clock skew
PUBLIC KEY AUTHENTICATION
Sign and encrypt with nonce…
 Secure
Encrypt and sign with nonce…
 Secure
Sign and encrypt with timestamp…
 Secure
Encrypt and sign with timestamp…
 Insecure
Protocols can be subtle!
PUBLIC KEY AUTHENTICATION
WITH TIMESTAMP T
“I’m Alice”, [{T, K}Bob]Alice

[{T +1}Alice]Bob

Alice Bob

 Is this “encrypt and sign” secure?

o Yes, seems to be OK
 Does “sign and encrypt” also work here?
KEY DISTRIBUTION USING
SYMMETRIC-KEY
KERBEROS
In Greek mythology, Kerberos is 3-headed dog that guards
entrance to Hades
 “Wouldn’t it make more sense to guard the exit?”

In security, Kerberos is an authentication protocol based

on symmetric key crypto
 Originated at MIT
 Based on work by Needham and Schroeder
 Relies on a Trusted Third Party (TTP)
 https://www.youtube.com/watch?v=_44CHD3Vx-0
MOTIVATION FOR KERBEROS
Authentication using public keys
 N users  N key pairs

Authentication using symmetric keys

 N users requires (on the order of) N2 keys

Symmetric key case does not scale

Kerberos based on symmetric keys but only requires N
keys for N users
- Security depends on TTP
+ No PKI is needed
KERBEROS KDC
Kerberos Key Distribution Center or KDC
 KDC acts as the TTP
 TTP is trusted, so it must not be compromised

KDC shares symmetric key KA with Alice, key KB with

Bob, key KC with Carol, etc.
And a master key KKDC known only to KDC
KDC enables authentication, session keys
 Session key for confidentiality and integrity
KERBEROS TICKETS
KDC issue tickets containing info needed to access
network resources
KDC also issues Ticket-Granting Tickets or TGTs that
are used to obtain tickets
Each TGT contains
 Session key
 User’s ID
 Expiration time

Every TGT is encrypted with KKDC

 So, TGT can only be read by the KDC
KERBERIZED LOGIN
Alice enters her password
Then Alice’s computer does following:
 Derives KA from Alice’s password
 Uses KA to get TGT for Alice from KDC

Alice then uses her TGT (credentials) to securely

access network resources
Plus: Security is transparent to Alice
Minus: KDC must be secure  it’s trusted!
 KERBERIZED LOGIN
Alice wants

Alice’s a TGT
password
E(SA,TGT,KA)
Computer KDC
Alice

Key KA = h(Alice’s password)

KDC creates session key SA
Alice’s computer decrypts SA and TGT
 Then it forgets KA

TGT = E(“Alice”, SA, KKDC)

 ALICE REQUESTS “TICKET TO BOB”
I want to
talk to Bob
Talk to Bob REQUEST

REPLY

Alice Computer KDC

REQUEST = (TGT, authenticator)

 authenticator = E(timestamp, SA)

REPLY = E(“Bob”, KAB, ticket to Bob, SA)

 ticket to Bob = E(“Alice”, KAB, KB)
KDC gets SA from TGT to verify timestamp
 ALICE USES TICKET TO BOB
ticket to Bob, authenticator

E(timestamp + 1, KAB)

Alice’s Bob
Computer

ticket to Bob = E(“Alice”, KAB, KB)

authenticator = E(timestamp, KAB)
Bob decrypts “ticket to Bob” to get KAB which he then uses to
verify timestamp
KERBEROS
Key SA used in authentication
 For confidentiality/integrity

Timestamps for authentication and replay protection

Recall, that timestamps…
 Reduce the number of messageslike a nonce that is known in advance
 But, “time” is a security-critical parameter
KERBEROS QUESTIONS
When Alice logs in, KDC sends E(SA, TGT, KA) where TGT =
E(“Alice”, SA, KKDC)
Q: Why is TGT encrypted with KA?
A: Extra work for no added security!

In Alice’s “Kerberized” login to Bob, why can Alice

remain anonymous?
Why is “ticket to Bob” sent to Alice?
 Why doesn’t KDC send it directly to Bob?
KERBEROS ALTERNATIVES
Could have Alice’s computer remember password and use
that for authentication
 Then no KDC required
 But hard to protect passwords
 Also, does not scale

Could have KDC remember session key instead of putting

it in a TGT
 Then no need for TGT
 But stateless KDC is major feature of Kerberos
KERBEROS KEYS
In Kerberos, KA = h(Alice’s password)
Could instead generate random KA
 Compute Kh = h(Alice’s password)
 And Alice’s computer stores E(KA, Kh)

Then KA need not change when Alice changes her

password
 But E(KA, Kh) must be stored on computer

This alternative approach is often used

 But not in Kerberos
THANK YOU