• Attacks on cryptography– Cyphertext, known pltext, chosen pltext, MITM, brute-force

• Types of ciphers– Mix of substitution and transposition– Monoalphabetic, homophonic, polygram, polyalphabetic – Symmetric (stream, block), asymmetric

• RNGs, block cipher modes (ECB, CFC, CFB, OFB)• Public key cryptography

– Modular exponentiation for encryption/decryption• One-way hash functions

– Collision-free, collision-resistant• MD5, SHA, DES, AES (not on exams)

Summary From the Last Lecture

• Confidentiality, integrity, non-repudiation– M, E(M), H(M), E(H(M)), H(E(M))– M + H(M)– M + E(H(M))– M + H(E(M))– E(M) + H(M)– E(M) + E(H(M)) – E(M) + H(E(M))

When/How to Encrypt/Hash?

• Chosen paper must talk about cryptography, authentication, authorization or policy– Select from venues listed on the class Web page– Email me your chosen paper to verify it fits the topic

• Write 2-4 page report– Summary of problem, why is it important and hard,

solution summary, evaluation and results, your opinion and your ideas

– Originality, clearness, writing style, must have all sections

– Proof-read!!– Start now!

First Report Due in Three Weeks

Key Exchange

Shared Key Exchange Problem• How do Alice and Bob exchange a shared secret?• Offline

– Doesn’t scale– Need a trusted third party

• Using public key cryptography (possible)• Using specially crafted messages (Diffie Hellman)• Using a trusted third party (KDC)

– Secrets should never be sent in clear– We should prevent replay attacks– We should prevent reuse of old keys

Exchange a secret with someone you never met while shouting in a room full of people

Alice and Bob agree on g and large nAlice chooses random a, sendsBob chooses random b, sendsAlice takes Bob’s message and calculates

Bob does the same; now they both know shared secret

nga mod

ngb mod

ngab mod

ngab mod

Diffie Hellman Key Exchange

• Building up to Needham Schroeder/Kerberos• User sends req. to KDC (key distrib. center)• KDC generates a shared key: Kc,s

• Keys KKDC,C and KKDC,S are preconfigured• No keys ever traverse net in the clear• Why are identities in tickets?

KDC Based Key Distribution

C KDC S3. EKKDC,S{C, Kc,s}

2. EKKDC,C{S, Kc,s}

1. C, S

ticket

• KDC does not have to talk both to C and S

• Messages 2 or 3 can be replayed by M– Force C and S to use same secret for a long time– Cause S to have an old ticket, break comm. w C

KDC Based Key Distribution

CKDC

S

ticketS = EKKDC,S{C, Kc,s}

2. EKKDC,C{S, Kc,s}, ticketS

1. C, S

3. ticketS

• Use nonces to prevent replay attacks

Needham-Shroeder Key Exchange

C

KDC

S

ticketS = EKKDC,S{C, Kc,s}

2. EKKDC,C{N1, S, Kc,s, ticketS}

1. N1, C, S

3. EKC,S{N2}, ticketS

4. EKC,S{N2-1, N3}

5. EKC,S{N3-1}

• Why N1?

• Why N2?

• Why N3?

• Why encrypt ticketS

Whys …

• What happens if attacker gets session key?– Can reuse old session key to answer challenge-

response, generate new requests, etc– Need timestamps to ensure freshness = tickets

expire after some time

Problem

• Introduce Ticket Granting Server (TGS)– Daily ticket plus session keys

• Authentication server (AS) authenticates users• TGS+AS = KDC

– This is modified Needham-Schroeder– Basis for Kerberos

Solution

Third-party authentication service– Distributes session keys for authentication,

confidentiality, and integrity

Kerberos

TGS

4. TGSRep

3. TGSReq

AS

1. ASReq2. ASRep

C S5. SReq

• ASReq = userID, TGS, lifetime1

• TTGS = EKAS,TGS(TGS, C, KTGS,C, timestamp1, lifetime2)

• ASRep = EKuser(KTGS,C, TGS, timestamp2, lifetime2), TTGS

• TGSReq = TTGS, EKTGS,C(C, timestamp3), S, lifetime3

• TS = EKS,TGS(S, C, KS,C, timestamp4, lifetime4)

• TGSRep = TS, EKC,TGS(KS,C, S, timestamp5, lifetime4)

• SReq = EKC,S{C, timestamp6}, TS

KerberosKuser = f(passuser)

Public Key Exchange Problem

• How do we verify an identity:– Alice sends to Bob her public key Pub(A)– Bob sends to Alice his public key Pub(B)– How do we ensure that those keys really belong to

Alice and Bob? Need a trusted third party

• Public key is public but …– How does either side know who and what the key is

for? • Does this solve key distribution problem?

– No – while confidentiality is not required, integrity is• Still need trusted third party

– Digital certificates – certificate authority (CA) signs identity+public key tuple with its private key

– Problem is finding a CA that both client and server trust

Public Key Distribution

Man-in-the-Middle Attack On Key Exchange

• Alice sends to Bob her public key Pub(A)• Mallory captures this and sends to Bob Pub(M)• Bob sends to Alice his public key Pub(B)• Mallory captures this and sends to Alice Pub(M)• Now Alice and Bob correspond through Mallory

who can read/change all their messages

Key Exchange With Interlock Protocol

• First four steps are the same– Alice to Bob her public key Pub(A)– Mallory captures this and sends to Bob Pub(M)– Bob sends to Alice his public key Pub(B)– Mallory captures this and sends to Alice Pub(M)

• Alice encrypts a message in Pub(M) but sends half to Bob – Mallory cannot recover this message and duplicate it

• This works if Mallory cannot mimic Alice’s and Bob’s messages

Digital Certificates

• Everyone has Trent’s public key• Trent signs both Alice’s and Bob’s public keys – he

generates public-key certificate• When they receive keys, verify the signature• Mallory cannot impersonate Alice or Bob because

her key is signed as Mallory’s• Certificate usually contains more than the public

key – Name, network address, organization

• Trent is known as Certificate Authority (CA)

• Authentication steps– Alice provides nonce, or a timestamp is used

instead.– Bob selects session key and sends it to Alice with

nonce, encrypted with Bob’s private key and Alice’s public key, sends Bob’s certificate too

– Alice validates certificate – it is really Bob’s key inside

– Alice checks signature on nonce – Bob really generated the message

Certificate-Based Authentication

• Pretty Good Privacy– “Web of Trust”– Public key, identity association is signed by

many entities– Receiver hopefully can locate several signatures

that he can trust– Like an endorsement scheme

PGP

• Assumes strict hierarchy of certificate authorities– Nodes in the hierarchy can delegate trust to

lower levels

X.509

• User keys installed on server out of band– User logs in with a password– Copies her public key onto server

• Weak assurance of server keys– User machine remembers server keys on first

contact– Checks if this is still the same host on

subsequent contact– But no check on first contact

SSH

• Revocation lists (CRL’s)– Long lists– Hard to propagate

• Lifetime / Expiration– Short life allows assurance of validity at time of

issue• Real time validation

– Online Certificate Status Protocol (OCSP)– Receiver of a certificate asks the CA who signed it

if corresponding private key was compromised– Can cache replies

Recovery From Stolen Private Keys

• Group key vs. individual key– Proves that one belongs to the group vs. proving

an individual identity– E.g., used for multicast messages

Group Keys

• Revoking access– Change keys, redistribute

• Joining and leaving groups– New members cannot read old messages on join –

backward secrecy – use old key to generate new one– How to revoke access – forward secrecy – much harder

• Robustness– Coping with network partitioning

• Efficiency– Cost of use, verification, exchange

Group Key Management

• Centralized– Single entity issues keys– Optimization to reduce traffic for large groups– May utilize application specific knowledge

• Decentralized– Employs sub managers

• Distributed– Members do key generation– May involve group contributions

Group Key Management

Authentication

• Ideally– Who you are

• Practically– Something you know (e.g., password)– Something you have (e.g., badge)– Something about you (e.g., fingerprint)

Basis for Authentication

• Password or Algorithm– e.g. encryption key derived from password

• Issues– Someone else may learn it

• Find it, sniff it, trick you into providing it

– Other party must know how to check– You must remember it

Something You Know

Password Authentication• Alice inputs her password, computer verifies

this against list of passwords• If computer is broken into, hackers can learn

everybody’s passwords– Use one-way functions, store the result for

every valid password– Perform one-way function on input,

compare result against the list

Password Authentication• Hackers can compile a list of frequently used

passwords, apply one-way function to each and store them in a table – dictionary attack

• Host adds random salt to password, applies one-way function to that and stores result and salt value– Randomly generated, unique and long enough

Password Authentication• Someone sniffing on the network can learn the

password• Lamport hash or S-KEY – time-varying password

– To set-up the system, Alice enters random number R– Host calculates

x0=h(R), x1=h(h(R)), x2=h(h(h(R))),..., x100

– Alice keeps this list, host sets her password to x101

– Alice logs on with x100, host verifies h(x100)=x101, resets password to x100

– Next time Alice logs on with x99

Password Authentication• Someone sniffing on the network can learn the

password– Host keeps a file of every user’s public key– Users keep their private keys– When Alice attempts to log on,

host sends her a random number R– Alice encrypts R with her private key

and sends to host– Host can now verify her identity by

decrypting the message and retrieving R

• Key Distribution– Confidentiality not needed for public key– Can be obtained ahead of time

• Performance– Slower than conventional cryptography– Implementations used for key distribution, then use

conventional crypto for data encryption• Trusted third party still needed

– To certify public key– To manage revocation

Public Key Authentication