Introduction to Practical Cryptography

1
Introduction to Practical Cryptography

• Protocols

2
Agenda

• Authentication
• Security Handshakes
• One-way
• Two-way
• Mediated Authentication
• Kerberos

3
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 Mothers maiden
name jones Pets name snoopy
4
Network Authentication

• Password
• One-time Passwords (ex. tokens)
• Network address
• Caller-id - credit card
• IP address
• MAC address banks
• Cryptographic protocols

5
Concerns

• Impersonation
• Malicious insiders
• Eavesdropping
• Keyboard sniffers
• Shoulder-surfing
• Network sniffers
• Trojan horses

6
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

7
Password-based Authentication

• Proof by sharing
• Doesnt 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 dogs name
• post-it on monitor
• inconvenient to update, varying rules on what is
  appropriately complex, how often to change
• snoopy1, Snoopy1,
  snoopy-1

8
Storing Passwords

• Per-node
• Central repository
• Hashed passwords
• Password encryption
• Salted passwords

9
Password Guessing

• Online
• Limited tries, exponential delays, alarm
• But attacker can temporarily disable a users
  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

10
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

11
One-Time Passwords

• List of passwords used once only
• Need to re-initialize periodically

12
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

13
Lamports 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 Alices system
• Server uses hashn(password salt)

14
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

15
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

16
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

17
Pairwise Keying
Bobxyz Aliceabc Fey ghj George 123 Emily
mkl Dave klj
Bobxyz Alicewho Fey bin Carol 123 Emily
dog Dave cat
18
Trusted Intermediaries (KDC)
George-Bobxyz George-Alicewho George-Fey bin
Bob13 Carol 31 Dave 7 .
Key Distribution Center
19
KDC

• Can impersonate any node
• Single point of failure
• Potential bottleneck

20
Certificate Authority

• Central point for certificates
• Signs cert for Alice containing her public key
• Others need only CAs public key
• Revocation?
• Real time with online KDC
• Offline CA expiration date, certificate
  revocation list

21
Agenda

• Authentication
• Security Handshakes
• One-way
• Two-way
• Mediated Authentication
• Kerberos

22
Security Handshakes

• Considerations when creating protocols
• Attacks/Information leakage
• One-way
• Mutual Authentication

23
One-way Challenge-Response
Bob
Alice
Im Alice
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 Bobs 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

24
One-Way using Timestamp
Bob
Alice
Im Alice, f(K,timestamp)

• 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

25
One-way Using Public Key
Bob
Alice
Im Alice
Bob decrypts with Alices public key and verifies
R was returned.
R
RApriv
Bob
Alice
Im Alice
Alice proves to Bob she has her private key by
returning R
RApub
R
RAx R signed with Alices x key, where x is
private (priv) or public (pub) key
26
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

27
Mutual Authentication
28
Mutual Authentication with Secret Key
Bob
Alice
Im Alice
R1
f(K,R1)
R2
f(K,R2)
29
Mutual Authentication with Secret Key
More efficient version
Bob
Alice
Im Alice, R2
R1, f(K,R2)
f(K,R1)
30
Mutual Authentication with Secret Key
Reflection attack
Bob
Trudy
Im Alice, R2
Doesnt know K so cant send f(K,R1)
R1, f(K,R2)
Bob
Trudy
Im Alice, R1
Now use f(K,R1) in above attempt
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

31
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

Bob
Alice
Im Alice
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)
32
Timestamps
Bob
Alice
Im Alice, f(K,timestamp)
f(K,timestamp1)

• Same issues as before plus clock skew
• Any modification to timestamp will work

33
Mutual Authentication with Public Keys
Im Alice, R2Bpub
Bob
Alice
R1Apub, R2
R1

• how to obtains/store/validate Bobs public key

34
Session Key

• Once authentication occurs, want to encrypt data
  exchanged
• Session key
• If key to one session obtained, cant decrypt all
  sessions
• Dont want known/easy to derive relationship
  among session keys

35
Agenda

• Authentication
• Security Handshakes
• One-way
• Two-way
• Mediated Authentication
• Kerberos

36
Mediated Authentication

• Needham-Schroeder
• Otway-Rees

37
Needham-Schroeder
Bob
Alice
KDC
N1, Alice wants to talk to 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")

38
Expanded Needham-Schroeder

• Issue - ticket doesnt expire
• If Trudy obtains Alices key and ticket, Trudy
  can connect to Bob even if Alice changes key.

Bob
Alice
I want to talk to you
Ekb(Nb)
N1, Alice wants to talk to Bob, Ekb(Nb)
Nb is unique per session so cant reuse ticket
KDC
EKa(N1, "Bob", Kab, ticket) ticket EKb(Kab,
"Alice", Ekb(Nb))
EKab(N2), ticket
EKab(N2 - 1, N3)
EKab(N3 - 1)
39
Needham-Schroeder

• Reflection attack in last steps if ECB mode (and
  nonce size block size)
• Trudy-gtBob EKab(N2), ticket
• Bob-gtTrudy EKab(N2 - 1, N4)
• Trudy-gtBob EKab(N4), ticket
• Bob-gtTrudy EKab(N4 - 1, N5)
• Extract EKab(N4 - 1) and use in response of first
  run
• CBC solves this

Trudy doesnt have Kab to obtain N4, needs N4-1
in next step, so get Bob to encrypt N4-1 Extract
1st block of ciphertext
40
Otway-Rees
Bob
Alice
Nc, "Alice", "Bob", EKa(Na, Nc, "Alice", "Bob")
EKa(Na, Nc, "Alice", "Bob"), EKb(Nb, Nc, "Alice",
"Bob")

• Suspicious party should generate challenge

KDC
Nc, EKa(Na, Kab), EKb(Nb, Kab)
EKa(Na, Kab)
EKab(something recognizable)

• Bob cant 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

41
Encrypted Key Exchange (EKE)
Shared weak secret W hash(Alices password)
Bob
Alice, EW(ga mod p)
Alice
EW(gb mod p, C1)
Stores Alice, W
Both compute K gab mod p
EK(C1,C2)
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,
cant determine correct plaintext what is valid
plaintext of ga mod p, gb mod p ?
42
Kerberos

• Based on Needham-Schroeder
• Uses time and includes ticket expiration
• Later in lecture

43
Nonces

• Random number
• 128-bit value negligible chance of being repeated
• Timestamp
• Synchronization
• Predictable
• Sequence number
• Maintain state
• Predictable?

44
Random Numbers

• Be careful with seed
• Size
• Easily known value timestamp
• Divulging seed dont use some value included
  unencrypted in message

45
Performance

• Number of messages exchanged
• Number of operations
• using secret key algorithm
• using public key algorithm
• using hash
• And number of bytes involved

46
Checklist

• Eavesdropping
• Initiation of conversation/partial conversations
• Impersonation by accepting a connection
• Access to disk/database at either end
• Man-in-middle

47
Agenda

• Authentication
• Security Handshakes
• One-way
• Two-way
• Mediated Authentication
• Kerberos

48
Needham-Schroeder
Bob
Alice
KDC
N1, Alice wants to talk to 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")

49
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

50
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

51
Design Goals

• Users only have passwords to authenticate
  themselves
• The network is completely insecure
• Its possible to protect the Kerberos server
• The workstations have not been tampered with (not
  a safe assumption)

52
Resources Protected

• Network access to home directory
• Printer
• IM system
• Remote login
• Anything else that requires authentication

53
Principals

• A Kerberos entity is known as a principal
• Could be a user or a system service
• Principal names are tuples
• V4 ltprimary name, instance, realmgt
• V5 ltprimary name variable fields, realmgt
• The realm identifies the Kerberos server

54
How Kerberos Works

• Users present tickets cryptographically sealed
  messages with session keys and identities to
  obtain a service.
• Use Needham-Schroeder (with password as Alices
  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 TGTs key) in a
  Needham-Schroeder dialog to obtain keys for each
  actual service

55
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

56
Kerberos Data Flow
TGT is ticket granting ticket
57
Obtaining TGT
Alice
Workstation
KDC
Alice, password
AS_REQ Alice needs a TGT
Creates session key SA Looks up Alices master
key KA Create TGT EK_KDC(Alice,SA,expire time)
AS_REP EKA(SA,TGT)
KDC stateless sends ticket, does not need to
save a copy Workstation sends TGT when Alice
needs to access remote resource
AS_REQ authentication server request AS_REP
authentication server reply TGT ticket granting
ticket K_KDC is KDCs master key
58
Ticket Request
TGS_REQ Alice wants to talk to Bob TGT
Authenticator ESA(timestamp)
Login to Bob
Alice
KDC
Workstation
Creates key KAB Decrypts TGT to get SA Decrypts
authenticator to verify timestamp Looks up Bobs
key KB Creates ticket EKB(Alice, KAB)
TGS_REP ESA(Bob, KAB, ticket to Bob)
59
Access Remote Resource
AP_REQ Ticket to Bob EKB(Alice,
KAB) Authenticator EKAB(timestamp)
Bob
Workstation (Alice)
AP_REP EKAB(timestamp1)
60
Messages

• Message fields listed in text
• Part of assigned readings
• Know what they mean/are for
• Dont need to memorize list of fields for midterm

61
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
• Theyre encrypted in a key shared by the KDC and
  the service

62
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 its 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
  clients principal name, extracted from the
  ticket

63
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

64
Bidirectional Authentication

• Sometimes, the client wants to be sure of the
  servers identity
• It asks the server to prove that it, too, knows
  the session key
• The server replies with EKAB(timestamp1) using
  the same timestamp as was in the authenticator

65
Ticket Lifetime

• TGTs typically last about 812 hours the length
  of a login session
• Service tickets can be long- or short-lived, but
  dont outlive the TGT
• Live tickets are cached by the client
• When service tickets expire, theyre
  automatically and transparently renewed

66
Inter-Realm Tickets

• A ticket from one realm cant be used in another,
  since a KDC in one realm doesnt 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
  realms KDC
• The remote realm trusts the users KDC to vouch
  for the users identity
• It then issues service tickets with the original
  realms name for the principal, not its own realm
  name

67
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 dont interoperate well.
• Users can supply some authorization data, too, to
  restrict what other services do with proxy
  tickets

68
Proxy Tickets

• Suppose a client wants to print a file
• The print spooler doesnt want to copy the users
  file thats expensive
• The user obtains a proxy ticket granting the
  print spooler access to its files
• The print spooler uses that ticket to read the
  users file

69
Restricting the Print Spooler

• The client doesnt 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.

70
Limitations of Kerberos

• Ticket cache security
• Password-guessing
• Subverted login command

71
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. . .

72
Subverting Login

• No great solutions.
• Keystroke loggers are a real threat today
• Some theoretical work on secure network booting

73
Version 5 Changes
74
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 Bobs 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

75
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, wont remain open
• Postdating
• Grant ticket to run some process in future
• Batch job at end of week but requested ticket at
  beginning of week

76
Key Version

• Suppose Alice has ticket to Bob
• Bob changes his key with KDC
• KDC keeps versions both versions of Bobs key
  (key, version)
• Alices ticket keeps working until it expires
• Any other renewable or post-dated ticket will
  work with old key

77
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 Alices password, still can
  compute both master keys
• But R1 and R2 dont have the others master key
  for Alice. If attacker breaks into one, wont get
  both keys.

78
Repairs

• Insert new cipher (AES) to replace DES
• Checksum fix for integrity replaced by choice
  of algorithm
• PCBC replaced by choice (AES-CBC common)

79
Hierarchy of Realms
H to D, go through E then B List transited realms
in ticket, dont give transited realms power to
impersonate others If dont trust one realm, all
realms visited after that one are suspect
80
Hierarchy of Realms
May have short cut links F talks directly to B
instead of C then A then B
A
B
C
F
D
E
G
H
J
I
81
Password Guessing

• V4 anyone can send ticket request to KDC

Alice wants to talk to Bob
Trudy
KDC

• V5 include encrypted timestamp

Alice wants to talk to Bob, EKa(timestamp)
Alice
KDC
82
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

83
Password Guessing

• On many Kerberos systems, anyone can ask the KDC
  for a TGT
• Theres 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
• Its still verifiable plaintext, but collecting
  TGTs becomes harder again

84
Multiple Sessions Added Security

• Alice opens two sessions to Bob
• Dont want Trudy swapping messages between
  sessions
• Alice specifies different session key to use for
  each

85
Other Protocols in Practice

• SSH
• TLS
• IPsec
• Application aware transport layer or above
• Application not aware - IP layer