Summary From the Last Lecture
• 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)
When/How to Encrypt/Hash?
• 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))
First Report Due in Three Weeks
• 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!
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
Diffie Hellman Key Exchange
 Exchange
a secret with someone you never
met while shouting in a room full of people
 Alice
and Bob agree on g and large n
 Alice
chooses random a, sends g a mod n
 Bob
chooses random b, sends g b mod n
 Alice
takes Bob’s message and calculates
g ab modn
 Bob does the same; now they both know
shared secret g ab modn
KDC Based Key Distribution
• Building up to Needham Schroeder/Kerberos
• User sends req. to KDC (key distrib. center)
• KDC generates a shared key: Kc,s
1. C, S
C
3. EKKDC,S{C, Kc,s}
KDC
ticket
2. EKKDC,C{S, Kc,s}
• Keys KKDC,C and KKDC,S are preconfigured
• No keys ever traverse net in the clear
• Why are identities in tickets?
S
KDC Based Key Distribution
• KDC does not have to talk both to C and S
ticketS = EKKDC,S{C, Kc,s}
1. C, S
KDC
C
2. EKKDC,C{S, Kc,s}, ticketS
S
3. ticketS
• 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
Needham-Shroeder Key Exchange
• Use nonces to prevent replay attacks
ticketS = EKKDC,S{C, Kc,s}
1. N1, C, S
KDC
2. EKKDC,C{N1, S, Kc,s, ticketS}
C
3. EKC,S{N2}, ticketS
4. EKC,S{N2-1, N3}
5. EKC,S{N3-1}
S
Whys …
•
•
•
•
Why N1?
Why N2?
Why N3?
Why encrypt ticketS
Problem
• What happens if attacker gets session key?
– Can reuse old session key to answer challengeresponse, generate new requests, etc
– Need timestamps to ensure freshness = tickets
expire after some time
Solution
• 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
Kerberos
Third-party authentication service
– Distributes session keys for authentication,
confidentiality, and integrity
AS
TGS
3. TGSReq
2. ASRep
1. ASReq
4. TGSRep
C
5. SReq
S
Kerberos
•
•
•
•
•
•
•
Kuser = f(passuser)
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
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 Distribution
• 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
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)
Certificate-Based Authentication
• 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
PGP
• 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
X.509
• Assumes strict hierarchy of certificate
authorities
– Nodes in the hierarchy can delegate trust to
lower levels
SSH
• 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
Recovery From Stolen Private Keys
• 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
Group 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 Key Management
• 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
Authentication
Basis for Authentication
• Ideally
– Who you are
• Practically
– Something you know (e.g., password)
– Something you have (e.g., badge)
– Something about you (e.g., fingerprint)
Something You Know
• 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
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
Public Key Authentication
• 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