Introduction to Practical
Cryptography
Protocols
Agenda
• Authentication
• Security Handshakes
– One-way
– Two-way
• Mediated Authentication
• Kerberos
Authentication
Prove continuity in relationship
– Basis of trust
– Identification
Who you are
(biometrics)
Physical authentication:
where you are
What you have
(tokens)
What you know
Password: snoopy1
Mother’s maiden name: jones
Pets name: snoopy
Network Authentication
• Password
• One-time Passwords (ex. tokens)
• Network address
– Caller-id - credit card
– IP address
– MAC address – banks
• Cryptographic protocols
Concerns
• Impersonation
• Malicious insiders
• Eavesdropping
– Keyboard sniffers
– Shoulder-surfing
– Network sniffers
– Trojan horses
2-Way Authentication
• Authentication often needed in both
directions
• Server trusting user is not only concern
– User must trust server
– Ex. User accessing online bank account
• Variety of “solutions” in user applications
Password-based Authentication
• Proof by sharing
• Doesn’t prevent insider attacks (system admin)
• What is an appropriate password
– length? snoopy, snoopy1, snoopy12
– reusable ? snoppy1, snoopy2, …. snoopy10, snoopy1
– timeframe?
• How to do initial password distribution? lastname123,
employee#
• Simple approach, works with humans
… until user has too many to remember
–
–
–
–
reuse across systems
Variations of something common: dog’s name
post-it on monitor
inconvenient to update, varying rules on what is appropriately
complex, how often to change
snoopy1, Snoopy1, snoopy-1
Storing Passwords
•
•
•
•
Per-node
Central repository
Hashed passwords
Password encryption
– Salted passwords
Password Guessing
• Online
– Limited tries, exponential delays, alarm
– But attacker can temporarily disable a user’s account –
ex. 3 tries and account locked until user calls help desk
• Offline: “dictionary” attack
–
–
–
–
Must capture password file
Try "obvious" passwords: snoopy, snoopy1, 1snoopy
Significant dates, easy patterns, personal information
While most systems disallow “dictionary words”,
complexity rules still give information – know need a digit,
punctuation character …
Snoopy-12
Passwords as Keys
• Directly as the key
• Convert to secret key
– Transient, one-way transformation (hash)
– Increase work of attacker
• Seed to pseudo-random number generator
One-Time Passwords
• List of passwords used once only
• Need to re-initialize periodically
OTPs – List Based
• Example:
–
–
–
–
–
Hash password 1000 times, store result on server
Client hashes 999 times, sends to server
Server verifies hash of received value matches stored
result
Store received hash
• Must be re-initialized periodically - over secure
channel
Lamport’s Hash
•
•
•
•
One-time passwords
Server stores n, hashn(password)
User sends x = hashn-1(password)
Server computes hash(x), if = stored value, replaces stored value
with n-1 , x
•
•
•
•
Safe from eavesdropping, server compromise not a problem for user
No public key cryptography
Authentication not mutual
Add salt to password before hashing
– In case Alice uses same password on multiple systems
– Salt must be stored on Alice’s system
– Server uses hashn(password | salt)
OTP Generators (Tokens)
• Examples
– RSA
– VASCO Digipass
• Use a block cipher
– Repeatedly encrypt
– Continuously update every x seconds
– Update each time user presses button
• Some work in both directions
– Customer enters OTP
– Server returns OTP, customer (manually) compares it
to value on token
Tokens - Issues
• Help desk required
– Synchronization not perfect
– Premature battery death
• Cost
– $15-$25
– banks with million customers
• User still needs pin (something you know + something
you have)
• “Necklace of Tokens” issue
– Only recently integrated with cell phones
– Still rare to have multiple tokens on single device
• Non-standard algorithms
– OATH effort
Cryptographic Authentication
• Tokens, smart cards use crypto
• Use a password (or key) in a
cryptographic protocol
– Prove possession of key
– Mutual authentication
• Usually coupled with encryption of data
after authentication
• Certificates
– PKI covered in another lecture
Pairwise Keying
Bob:xyz
Alice:who
Fey: bin
Carol: 123
Emily: dog
Dave: cat
Bob:xyz
Alice:abc
Fey: ghj
George: 123
Emily: mkl
Dave: klj
Trusted Intermediaries (KDC)
Key Distribution Center
George-Bob:xyz
George-Alice:who
George-Fey: bin
…
Bob:13
Carol: 31
Dave: 7
….
KDC
• Can impersonate any node
• Single point of failure
• Potential bottleneck
Certificate Authority
• Central point for certificates
• Signs cert for Alice containing her public
key
• Others need only CA’s public key
• Revocation?
– Real time with online KDC
– Offline CA –expiration date, certificate
revocation list
Agenda
• Authentication
• Security Handshakes
– One-way
– Two-way
• Mediated Authentication
• Kerberos
Security Handshakes
• Considerations when creating protocols
– Attacks/Information leakage
– One-way
– Mutual Authentication
One-way Challenge-Response
Alice
I’m Alice
Bob
challenge R
K = shared key
f(K,R)
f:
– encryption function – Bob just decrypts and verifies time in within
allowed skew
– hash – Bob needs to hash all times in allowable interval or Alice sends
time
Problems?
– Authentication not mutual
– Connection hijacking after authentication – attacker spoofs Alice or
Bob’s source address and send packets if conversation not encrypted
– Off-line password/key attack – depends on length of K
– Compromise of database/disk if K is stored, or temporary memory
access
One-Way using Timestamp
Alice
I’m Alice, f(K,timestamp)
Bob
• Problems?
– Impersonate Alice if intercept and send message – race condition
– Keep list of used time stamps to prevent quick replay, but if use same K
with multiple servers, could send message to another server and
impersonate Alice
– Clock skew/synchronization
One-way Using Public Key
Alice
I’m Alice
Bob
Bob decrypts with Alice’s
public key and verifies R
was returned.
R
[R]Apriv
Alice
Alice proves to Bob
she has her private
key by returning R
I’m Alice
Bob
[R]Apub
R
[R]Ax = R signed with Alice’s
x key, where x is private
(priv) or public (pub) key
One-way Problems
• First case:
– Can send anything to Alice as R and get Alice
to sign it
• Second case:
– Intercepted an encrypted message for Alice,
send it and get Alice to decrypt it
Mutual Authentication
Mutual Authentication with Secret Key
Alice
I’m Alice
R1
f(K,R1)
R2
f(K,R2)
Bob
Mutual Authentication with Secret Key
More efficient version:
Alice
I’m Alice, R2
R1, f(K,R2)
f(K,R1)
Bob
Mutual Authentication with Secret Key
Reflection attack:
Trudy
Doesn’t
know K so
can’t send
f(K,R1)
I’m Alice, R2
Bob
R1, f(K,R2)
Trudy
Now use
f(K,R1) in
above attempt
I’m Alice, R1
Bob
R3, f(K,R1)
Solutions:
•Separate keys for each direction
•Requirements on R values: odd in one direction, even in
the other, concatenate with senders’ name
Password/Key Guessing
• Also note, Trudy can get Bob to encrypt a value (or a
several of values) and then try an offline attack to guess
K
• Have Bob return R1 value for Alice to encrypt
Alice
I’m Alice
Bob
R1
R2, f(K,R1)
f(K,R2)
Now Bob would have to reuse R1 in order for
Trudy, who eavesdrops, to be able to use f(K,R1)
Timestamps
Alice
I’m Alice, f(K,timestamp)
f(K,timestamp+1)
• Same issues as before plus clock skew
• Any modification to timestamp will work
Bob
Mutual Authentication with Public Keys
Alice
I’m Alice, [R2]Bpub
Bob
[R1]Apub, R2
R1
• how to obtains/store/validate Bob’s public key
Session Key
• Once authentication occurs, want to encrypt
data exchanged
• Session key
• If key to one session obtained, can’t decrypt all
sessions
• Don’t want known/easy to derive relationship
among session keys
Agenda
• Authentication
• Security Handshakes
– One-way
– Two-way
• Mediated Authentication
• Kerberos
Mediated Authentication
• Needham-Schroeder
• Otway-Rees
Needham-Schroeder
Alice
N1, Alice wants to talk to Bob
KDC
Bob
EKa(N1, "Bob", Kab, ticket)
N1 authenticates KDC to Alice
ticket = EKb(Kab, "Alice")
EKab(N2), ticket
Bob decrypts
ticket to get Kab
EKab(N2 - 1, N3)
EKab(N3 - 1)
Nonces used to verify
each end has Kab
•
N1, N2, N3 are nonces ("number used once")
Expanded Needham-Schroeder
• Issue - ticket doesn’t expire
• If Trudy obtains Alice’s key and ticket, Trudy can connect to Bob
even if Alice changes key.
Alice
Bob
I want to talk to you
Ekb(Nb)
N1, Alice wants to talk to Bob, Ekb(Nb)
KDC
EKa(N1, "Bob", Kab, ticket)
ticket = EKb(Kab, "Alice", Ekb(Nb))
EKab(N2), ticket
EKab(N2 - 1, N3)
EKab(N3 - 1)
Nb is unique per session
so can’t reuse ticket
Needham-Schroeder
• Reflection attack in last steps if ECB
mode (and nonce size = block size)
Trudy->Bob: EKab(N2), ticket
Bob->Trudy: EKab(N2 - 1, N4)
Trudy doesn’t have
Kab to obtain N4,
needs N4-1 in next
step, so get Bob to
encrypt N4-1
Extract 1st block of
ciphertext
Trudy->Bob: EKab(N4), ticket
Bob->Trudy: EKab(N4 - 1, N5)
Extract EKab(N4 - 1) and use in response of
first run
• CBC solves this
Otway-Rees
Alice
Nc, "Alice", "Bob", EKa(Na, Nc, "Alice", "Bob")
Suspicious party should
generate challenge
Bob
EKa(Na, Nc, "Alice", "Bob"),
EKb(Nb, Nc, "Alice", "Bob")
KDC
Nc, EKa(Na, Kab), EKb(Nb, Kab)
EKa(Na, Kab)
EKab(something recognizable)
•Bob can’t decipher most of first message – forwards it to KDC
•KDC verifies Nc matches in messages from Alice and Bob
•KDC gives Bob message to forward to Alice
•Alice trusts KDC and Bob are real - KDC would not have continued process if
Bob did not have Kb to encrypt Nc and KDC was able to encrypt Na in message
containing Kab
•Bob trusts KDC – was able to encrypt Nb in message containing Kab
•Last message proves to Bob that Alice knows Kab
Encrypted Key Exchange (EKE)
Shared weak secret W = hash(Alice’s password)
Bob
“Alice”, EW(ga mod p)
Alice
EW(gb mod p, C1)
Both compute
K = gab mod p
EK(C1,C2)
Stores
Alice, W
Both compute
K = gab mod p
EK(C2)
Diffie-Hellman key exchange with exchange encrypted – removes man in middle
Mutual authentication
If try offline password attack, can’t determine correct plaintext – what is valid plaintext of
ga mod p, gb mod p ?
Kerberos
• Based on Needham-Schroeder
• Uses time and includes ticket expiration
• Later in lecture
Nonces
• Random number
– 128-bit value negligible chance of being
repeated
• Timestamp
– Synchronization
– Predictable
• Sequence number
– Maintain state
– Predictable?
Random Numbers
•
•
•
•
Be careful with seed
Size
Easily known value: timestamp
Divulging seed – don’t use some value
included unencrypted in message
Performance
• Number of messages exchanged
• Number of operations
– using secret key algorithm
– using public key algorithm
– using hash
• And number of bytes involved
Checklist
• Eavesdropping
• Initiation of conversation/partial
conversations
• Impersonation by accepting a connection
• Access to disk/database at either end
• Man-in-middle
Agenda
• Authentication
• Security Handshakes
– One-way
– Two-way
• Mediated Authentication
• Kerberos
Needham-Schroeder
Alice
N1, Alice wants to talk to Bob
KDC
Bob
EKa(N1, "Bob", Kab, ticket)
N1 authenticates KDC to Alice
ticket = EKb(Kab, "Alice")
EKab(N2), ticket
Bob decrypts
ticket to get Kab
EKab(N2 - 1, N3)
EKab(N3 - 1)
Nonces used to verify
each end has Kab
•
N1, N2, N3 are nonces ("number used once")
Overview
• Originally developed at MIT
• An essential part of Windows servers
• Authentication infrastructure
– Designed to authenticate users to servers
– Users must use their password as their initial
key and must not be forced to retype it
constantly
• Based on Needham-Schroeder, with
timestamps to limit key lifetime
Versions
• MIT support: version 4 end-of-life in 2006
– DES
– Protocol flaw
• Original Needham-Schroeder protocol implicitly requires nonmalleable
encryption: prevent an attacker, given a ciphertext, from producing a
different ciphertext whose plaintext is meaningfully related to the plaintext of
the original ciphertext.
• Kerberos version 4 fails to provide by inadequately authenticating its
messages. Nonmalleability concept was not well-developed at the time.
– nonstandard propagating cipher block chaining (PCBC) mode.
ciphertext block swaps being undetectable without additional integrity
checking.
– Implementation flaws
• Version 5
– Fixes/improvements (delegation, ticket lifetime, key versions …)
– Encoding changes
– Optional, variable-length fields, types
• Adds flexibility, but increases number of bytes per message and processing
overhead
Design Goals
• Users only have passwords to
authenticate themselves
• The network is completely insecure
• It’s possible to protect the Kerberos server
• The workstations have not been tampered
with (not a safe assumption)
Resources Protected
•
•
•
•
•
Network access to home directory
Printer
IM system
Remote login
Anything else that requires authentication
Principals
• A Kerberos entity is known as a principal
• Could be a user or a system service
• Principal names are tuples:
V4: <primary name, instance, realm>
V5: <primary name + variable fields, realm>
• The realm identifies the Kerberos server
How Kerberos Works
• Users present tickets — cryptographically sealed
messages with session keys and identities — to
obtain a service.
• Use Needham-Schroeder (with password as
Alice’s key) to get a Ticket-Granting Ticket
(TGT); this ticket (and the associated key) are
retained for future use during its lifetime.
• Use the TGT (and TGT’s key) in a NeedhamSchroeder dialog to obtain keys for each actual
service
Shared Secret
• Each principal (user, device) shares a
secret (master key) with the Kerberos
KDC
• For users, this is their password (actually,
a key derived from the password)
• The KDC is assumed to be secure and
trustworthy; anything it says can be
believed
Kerberos Data Flow
TGT is ticket granting ticket
Obtaining TGT
Alice
Alice, password
Workstation
AS_REQ
Alice needs a TGT
AS_REP
EKA(SA,TGT)
KDC
Creates session key SA
Looks up Alice’s master key KA
Create TGT EK_KDC(Alice,SA,expire time)
KDC stateless – sends ticket,
does not need to save a copy
AS_REQ: authentication server request
AS_REP: authentication server reply
TGT: ticket granting ticket
K_KDC is KDC’s master key
Workstation sends TGT when
Alice needs to access remote
resource
Ticket Request
Alice
Login to Bob
Workstation
TGS_REQ
Alice wants to talk to Bob
TGT
Authenticator = ESA(timestamp)
TGS_REP
ESA(Bob, KAB, ticket to Bob)
KDC
Creates key KAB
Decrypts TGT to get SA
Decrypts authenticator to verify
timestamp
Looks up Bob’s key KB
Creates ticket EKB(Alice, KAB)
Access Remote Resource
AP_REQ
Ticket to Bob = EKB(Alice, KAB)
Authenticator = EKAB(timestamp)
Workstation
(Alice)
AP_REP
EKAB(timestamp+1)
Bob
Messages
•
•
•
•
Message fields listed in text
Part of assigned readings
Know what they mean/are for
Don’t need to memorize list of fields for
midterm
Service Tickets
• Service tickets are almost identical to
ticket-granting tickets
• The differences is that they have the name
of a different service — say, “email” —
rather than the ticket-granting service
• They’re encrypted in a key shared by the
KDC and the service
Using Service Tickets
• The client sends the service ticket and an authenticator
to the service
• The service decrypts the ticket, using its own key
• The service knows it’s genuine, because only the KDC
knows the key used to produce it
• The service verifies that the ticket is for it and not some
other service
• It uses the enclosed key to decrypt and verify the
authenticator
• The net result is that the service knows the client’s
principal name, extracted from the ticket
Authentication, Not Authorization
• Kerberos is an authentication service
• It does not (usually) provide authorization
• The services know a genuine name for the
client, vouched for by the KDC
• They then make their own authorization
decision based on this name
Bidirectional Authentication
• Sometimes, the client wants to be sure of
the server’s identity
• It asks the server to prove that it, too,
knows the session key
• The server replies with EKAB(timestamp+1)
using the same timestamp as was in the
authenticator
Ticket Lifetime
• TGTs typically last about 8–12 hours —
the length of a login session
• Service tickets can be long- or short-lived,
but don’t outlive the TGT
• Live tickets are cached by the client
• When service tickets expire, they’re
automatically and transparently renewed
Inter-Realm Tickets
• A ticket from one realm can’t be used in another,
since a KDC in one realm doesn’t share secrets
with services in another realm
• Realms can issue tickets to each other
• A client can ask its KDC for a TGT to another
realm’s KDC
• The remote realm trusts the user’s KDC to
vouch for the user’s identity
• It then issues service tickets with the original
realm’s name for the principal, not its own realm
name
Putting Authorization in Tickets
• Under certain circumstances, tickets can contain
authorization information known or supplied to
the KDC
• Windows KDCs use this, to centralize
authorization data
• As a result, Windows and open source Kerberos
KDCs don’t interoperate well.
• Users can supply some authorization data, too,
to restrict what other services do with proxy
tickets
Proxy Tickets
• Suppose a client wants to print a file
• The print spooler doesn’t want to copy the
user’s file; that’s expensive
• The user obtains a proxy ticket granting
the print spooler access to its files
• The print spooler uses that ticket to read
the user’s file
Restricting the Print Spooler
• The client doesn’t want the spooler to have
access to all of its files
• It lists the appropriate file names in the proxy
ticket request; the KDC puts that list of names
into the proxy ticket
• When the print spooler presents the proxy ticket
to a file server, it will only be given those files
• Note: the file server must verify that the client
has access to those files.
Limitations of Kerberos
• Ticket cache security
• Password-guessing
• Subverted login command
Ticket Cache Security
• Where are cached tickets stored?
• Often in /tmp — is the OS protection good
enough?
• Less of an issue on single-user
workstations; often a threat on multi-user
machines
• Note: /tmp needs to be a local disk, and
not something mounted via NFS. . .
Subverting Login
• No great solutions.
• Keystroke loggers are a real threat today
• Some theoretical work on secure network
booting
Version 5 Changes
Delegation
• Delegation of rights
– Alice wants Bob to access resource X on behalf of
Alice for time t.
• Example: Alice logs into host Bob then wants to log into host
X from Bob
– Alice can request ticket with Bob’s address or a list of
addresses
– Ticket can include application specific data – not used
by Kerberos but used by host
• Can set to not allow delegation
Ticket Lifetime
•
•
•
•
•
•
V4: 21 hours max
V5: up to Dec. 31, 9999
Lifetime in seconds
Not revocable – be careful
Time ticket granted, start time and stop time
Renew until – instead of long lifetime, give option to keep
renewing
– If stop using/needing ticket, won’t remain open
• Postdating
• Grant ticket to run some process in future
– Batch job at end of week but requested ticket at beginning of
week
Key Version
• Suppose Alice has ticket to Bob
• Bob changes his key with KDC
• KDC keeps versions both versions of
Bob’s key (key, version)
• Alice’s ticket keeps working until it expires
• Any other renewable or post-dated ticket
will work with old key
Master Keys and Realms
• Master keys – key between entity (such as Alice)
and KDC
• Alice registered to realms R1, R2
– Uses same password
• Hash password with realm name to get master
key
• If attacker gets Alice’s password, still can
compute both master keys
• But R1 and R2 don’t have the other’s master key
for Alice. If attacker breaks into one, won’t get
both keys.
Repairs
• Insert new cipher (AES) to replace DES
• Checksum fix for integrity – replaced by
choice of algorithm
• PCBC – replaced by choice (AES-CBC
common)
Hierarchy of Realms
A
B
D
C
F
E
G
H
I
J
H to D, go through E then B
List transited realms in ticket, don’t give transited realms power to
impersonate others
If don’t trust one realm, all realms visited after that one are suspect
Hierarchy of Realms
May have short cut links
F talks directly to B instead of
C then A then B
A
B
D
C
F
E
G
H
I
J
Password Guessing
• V4: anyone can send ticket request to KDC
Alice wants to talk to Bob
Trudy
KDC
• V5: include encrypted timestamp
Alice
Alice wants to talk to Bob,
EKa(timestamp)
KDC
Password-Guessing
• Kerberos tickets have verifiable plaintext
• An attacker can run password-guessing
programs on intercepted ticket-granting
tickets (Merritt and Bellovin invented EKE
while studying this problem with
Kerberos.)
• Kerberos uses passphrases instead of
passwords
• Does this make guessing harder? Not sure
Password Guessing
• On many Kerberos systems, anyone can ask the
KDC for a TGT
• There’s no need to eavesdrop to get them —
you can get all the TGTs you want over the
Internet.
• Solution: preauthentication
• The initial request includes a timestamp
encrypted with Kc
• It’s still verifiable plaintext, but collecting TGTs
becomes harder again
Multiple Sessions – Added Security
• Alice opens two sessions to Bob
• Don’t want Trudy swapping messages
between sessions
• Alice specifies different session key to use
for each
Other Protocols in Practice
• SSH
• TLS
• IPsec
• Application aware – transport layer or
above
• Application not aware - IP layer