Bishop, Chapter 10 Key Management

1
Bishop, Chapter 10 (Key Management)

• What's the essential problem(s) here?
• What's the difference between an interchange key
  and a session key, and why is the distinction
  important?

2
Key Exchange in "Classical" Systems

• What systems does this apply to?
• Remember the key-exchange protocol we talked
  about a while back

3
Key Exchange using Symmetric Cryptography (from
Chapter 9 notes)

• Suppose we have a trusted third party (the Key
  Distribution Center, aka Trent). Alice and Bob
  have registered secret keys with Trent. Alice
  wants to send a message to Bob
• Alice contacts Trent and requests a session key
  for Bob
• Trent generates a random key (the session key).
  He encrypts it once with Alice's secret key and
  once with Bob's secret key, and sends both copies
  to Alice.
• Alice decrypts her copy of the session key
• Alice sends Bob his copy of the session key,
  which he decrypts
• Alice and Bob communicate using DES (or some
  other symmetric key method) and this session key
• Eve cannot read the messages because she does not
  know the session key (having seen it only in
  encrypted form)
• Problems with this approach (apart from the
  reliance on Trent)?
• man-in-the middle attack? (Between Alice and Bob?
  Alice and Trent?)
• replay attack?

4
Wide-Mouth Frog

• A variant with fewer messages
• Alice sends this message to Trent A, EA(TA,B,K)
• A is Alice's name (or identifying string)
• T is a timestamp
• B is Bob's name
• K is a random session key (generated by Alice)
• EA(...) means the message is encrypted using the
  identity key Alice shares with Trent
• Trent decrypts the message, generates a new
  timestamp, and sends to Bob EB(TB,A,K)
• What are the main differences?
• How does this help foil a replay attack?
• What are the problems associated with using
  timestamps?

5
Needham-Schroeder

• Random numbers to foil replay attacks
• Alice sends to Trent A,B,RA
• where RA is a random number generated by Alice (a
  "nonce")
• nonce is a general term for a parameter that is
  to be used once only
• Trent sends to Alice EA(RA,B,K,EB(K,A))
• where K is a session key generated by Trent
• Alice decrypts, verifies RA extracts K
• Alice sends to Bob EB(K,A)
• Bob decrypts, extracts the session key, and sends
  to Alice EK(RB)
• Alice decrypts and sends back to Bob EK(RB 1 )
• Why does this prevent replay attacks? And at
  what cost?
• One problem with this is that the session keys
  are valuable. What happens if Mallory has been
  saving messages, and later gets the session key
  K?
• And how could you protect against this problem?

6
Otway-Rees

• Invalidating session keys without resorting to
  timestamps
• Alice sends to Bob I,A,B,EA(RA,I,A,B)
• where I is an index number of Alice's choosing
• Bob sends to Trent I,A,B,EA(RA,I,A,B),EB(RB,I,A,B
  )
• Trent sends to Bob I, EA(RA,K), EB(RB,K)
• Bob sends to Alice I, EA(RA,K)
• Alice verifies that I has not changed, decrypts
  the message, verifies that RA has not changed,
  and now can communicate with Bob using K.
• Replay attack?
• Key gets compromised later?

7
Kerberos

• Open-source authentication from MIT for use in
  client/server architectures
• Widely used to avoid sending passwords in
  plaintext in applications like email, terminal
  server, file transfer, line printer
• (alternative to SSL, which we will talk about
  later)
• Kerberos maintains the database of clients and
  keys (key encrypted password), so is
  incompatible with standard password file
  implementations
• client requests a ticket for a ticket-granting
  service (TGS) from the Kerberos service
• ticket is sent to the client using the client's
  secret key
• client requests a ticket from the TGS (say, to
  access a POP server)
• TGS sends back a ticket
• client contacts the POP server, presenting its
  ticket and an authenticator
• service grants access, and communicates with the
  client using a session key
• Note there are three different services
  Kerberos (user authentication), TGS (ticket
  granting to an authenticated user), POP (email
  service to an authenticated, ticketed user)

8
Kerberos Architecture
Permissions to use services Keys shared with
services
"Passwords" Keys shared with clients Keys shared
with TGS
Kerberos Server
Ticket Granting Server
Authenticate user Request ticket to uses TGS
Session key for TGS Ticket to use TGS
Ticket to use POP service Session key for POP
service
Ticket to use TGS Service name (POP)
Email client (Eudora, Pine)
FTP Server
Ticket to use POP service POP request
File transfer client (SFTP)
POP Server
(can assume authenticated user with proper
permissions)
9
Kerberos Messages (5 message types)

• Client to Kerberos asking for authentication to
  the TGS c, tgs
• c identifies the client, tgs identifies the
  ticket-granting service
• Kerberos to client K c, tgsKc, T c,tgsKtgs
• K c,tgs is a session key to be used for the
  client to communicate with the TGS
• Kc is the secret key shared between the client
  and Kerberos
• Ktgs is the secret key shared between the TGS and
  Kerberos
• Now the client has a key for communicating with
  the TGS, and also has an encrypted ticket to send
  to the TGS
• Client to TGS A c, sKc,tgs, T c,tgsKtgs
• A c, s is an authenticator constructed by the
  client
• Client passes the ticket on to the TGS

10
Kerberos Messages (cont.)

• TGS to client K c, sKc,tgs, T c,sKs
• K c, s is a session key generated by the TGS,
  enabling the client to talk to the service
• Ks is a secret key shared between the service and
  the TGS (notice the service doesn't talk to
  Kerberos at all)
• T c,s is another ticket, generated by the TGS,
  allowing access to the service
• Client to server A c, sKc,s, T c,sKs
• client presents both its authenticator and its
  ticket to the service itself
• client and service also have a session key to use
  for this exchange

11
Kerberos Tickets

• Ticket used to pass securely to the server the
  identity of the client for whom the ticket was
  issued
• Kerberos holds the passwords, TGS and other
  services need to think only about identities
• Ticket contains T c,s s, c, a, v, K c,sKs
• Ticket for client c to use service s
• a is client's network address
• v is a time interval for which the ticket is
  valid
• K c,s is session key generated for this
  interaction
• K S is the secret key shared between the service
  and Kerberos
• Client can use the ticket multiple times, until
  it times out

12
Kerberos Authenticators

• An authenticator is built by the client itself,
  every time it wants to use a service
• Authenticator of the form Ac,s c, tKc,s
• c is the client's name
• t is the timestamp
• Kc,s is the session key for communicating with
  the service (supplied by the TGS)
• An authenticator is constructed at each service
  call along with the ticket
• Notice that information like the client's name is
  redundant with information in the ticket, but it
  is being independently verified by the TGS
  (encrypted with its secret key) and the client

13
Possible Attacks on Kerberos

• Cache and replay authenticators
• these are timestamped, but might work during the
  lifetime of an authenticator and ticket
• counts on clocks being synchronized, and perhaps
  the clock synchronization protocol can be
  manipulated
• Password guessing
• collect a large number of Kerberos requests, and
  try to decrypt the passwords
• Hack the Kerberos software (Kerberos or TGT
  Server code)
• (true of any secure protocol implemented on an
  insecure system, e.g. universities)

14
Random Number Generation

• Effective implementation of these protocols
  depends crucially on being able to generate
  sequences of random numbers
• why?
• The real concept of interest is of a
  cryptographically random sequence n1, n2, ...,
  nk, nk1, ...
• you should have no better luck predicting n k1
  having seen the sequence up to nk

15
Implementations

• Ideally you would like your generator to base the
  next number on some randomly varying (physical)
  phenomenon
• some function of prevailing environment (weather,
  line voltage, ambient noise, etc. etc.)
• Of course that will be impossible for most
  general-purpose computer implementations
• also slow to "sample anew" for each number
• Most implementations are based on
• a seed (possibly provided by the package's user)
• some parameters (usually hard-wired into the
  algorithm)
• a deterministic algorithm for generating the next
  number in the sequence based on the previous
  sequence and the parameters
• This is pseudo-random rather than random because
• you know the next number with certainty if you
  know the seed and parameters
• you can probably infer the seed and parameters
  given a look at enough of the sequence

16
Implementations (cont.)

• Pseudo-random number generators take the form
• n k1 f(P nk, n k-1, ..., n0)
• where P is the parameter set, and f is some
  arbitrary function of the preceding members of
  the sequence
• As a practical matter (these things have to be
  fast)
• the next number doesn't depend on the whole
  sequence (requires lots of seeds otherwise)
• the function is very simple

17
Linear Congruential Generators

• Almost certainly what you have been using when
  you call the random() function in your favorite
  programming language
• Form of the function is x n1 (a xn b) mod
  m
• what are the parameters?
• how many seeds and why?
• what's the role of m?
• The period of a generator is the number of values
  it emits before it repeats its first number
• and what happens after it repeats its first
  number?
• what's the largest period we can hope for?
• Lots of techniques for choosing good parameter
  values that generate long-period generators based
  on the largest integer value stored on the
  machine
• These generators are very fast and easy to
  implement, but can easily be cracked.

18
Adequacy of Congruential Generators

• Cracking linear congruential generators has been
  done (the technology is 30 years old)
• (what exactly does it mean to crack it)
• Obvious variations are using a quadratic, cubic,
  or other polynomial of the previous input
• (why does this make it harder to crack?)
• technology for cracking an arbitrary polynomial
  is 10 years newer (or 20 years old depending on
  how you look at it)
• Schneier "The preponderance of evidence is that
  congruential generators aren't useful for
  cryptography. Linear congruential generators
  remain useful for noncryptographic applications,
  however, such as simulations. They are efficient
  and show good statistical behavior with respect
  to most reasonable empirical tests."
• (what's the take-home lesson?)

19
Alternative Generators

• The state of the art is get seed values from
  the environment, as close to random as you can
  get
• certain bits of the current time
• certain properties of the system environment
• preferably from a variety of dynamic,
  uncorrelated sources
• Use an ad hoc mixing function to permute the bits
  to get the random number
• The real problem is that this must be done at
  every request, which could potentially be very
  expensive

20
Key Management in PK Systems

• What are the problems associated with managing a
  key in a public-key system (since it's public,
  after all)?
• What are Alice's options for getting Bob's public
  key if she wants to send him a message (and how
  can they fail)?

21
Public Key Certificates

• Certificate a binding of a key to an identity
• the concept of an identity is kind of slippery
  we will assume that there is some name that
  uniquely identifies a subject
• A certificate is someone's public key, signed by
  a trustworthy person
• Trent says that this is Bob's public key, and I
  trust Trent
• But many problems arise
• how do I get Trent's public key
• how do I come to trust Trent
• how long should I trust the key
• in general, how does this work in the large

22
Certification Chains (X.509)

• Remember why we like public key systems in the
  first place (over private-key systems)
• why??
• The problem is ... there's no such thing as Trent
• but he has friends
• Certificate chains Alice trusts Charlie who
  trusts Trent. Doug vouches for Bob, Evelyn
  trusts Doug, Trent trusts Evelyn. So ...
• Doug signs Bob's key, which is signed by Evelyn,
  which is signed by Trent, which is signed by
  Charlie.
• as long as Alice has all the public keys
  involved, she is confident (?) that the key she
  thinks is Bob's is actually his
• unless ... ?

23
PGP

• What is it?
• a freeware email security program for signing
  and/or encrypting email messages
• a distributed "web of trust" method for
  distributed key management
• Uses standard public technology
• IDEA (a DES-like symmetric-key block cipher) for
  encryption
• RSA for key management and signature
• MD5 as a one-way hash function (for signing
  messages)

24
How you use it

• In the UNIX implementation, you have a bunch of
  shell scripts at your disposal
• generate and store a private key for yourself
• sign an email message
• encrypt an email message
• decrypt an email message (given that you have the
  public key)
• get somebody's public key securely
• express trust in somebody else's certification
• Email messages are "signed" by appending a PGP
  block to the bottom of the message that is the
  signed MD5 hash of the message
• You can broadcast your public key textually in
  the email message too (the PGP block)

25
PGP and Key Management

• Direct key signing
• Alice physically gives her public key to Bob, who
  knows her. He signs it and gives it back to her,
  keeping a copy for himself
• When Alice wants to communicate with Carol, Alice
  sends Carol a copy of her key signed by Bob
• if Carol trusts Bob and has his key, she accepts
  Alice's key as valid
• she also puts Alice's key on her "public key
  ring" (which already contains Bob's key

26
PGP and Degree of Trust

• Each signed key has a "trust" or "legitimacy"
  level
• How much does Carol trust that Bob can vouch for
  Alice?
• How much does Carol trust Bob's ability to sign
  keys in general?
• This is a fairly imprecise notion. There are
  only two concepts
• degree of trust in this signature which depends
  on the actual signatures involved (you can say
  how much you trust any particular individual)
• "degree of paranoia" are you sufficiently sure
  in order to act as though this is really Bob's
  key?
• And PGP does not take a stand on how much trust
  is enough it just provides an infrastructure
  for key exchange
• scripts for signing
• scripts for associating trust with a signature
• protocol for sending a signed key to somebody
  else
• parameter settings to sort email by "trustedness"

27
Key Revocation

• All certificates have an associated expiration
  date after that, nobody should trust the
  certificate
• But it's a real problem if Alice's private key is
  stolen before all the certificates expire
• What can Eve and Mallory do if
• they have Alice's private key and everybody
  thinks they know her public key
• they have Alice's private key but nobody trusts
  her public key any more
• In PGP, Alice sends out a key revocation
  certificate, and anybody who gets the certificate
  will remove Alice's signed key from their public
  key ring
• and at that point they will have to re-discover
  Alice's key
• but the problem is by the very nature of the PGP
  network there is no systematic way to broadcast
  the revocation

28
The Opposite Direction Certification Authorities

• Trent and his friends return.
• Suppose you are exchanging email with (or more
  commonly are visiting a web site of) somebody,
  and want to authenticate that site
• The certification authority (Verisign, Thawte)
• certifies sites by some kind of positive
  identification (phone)
• provides clients (browsers) with a self-signed
  and trusted key
• When you visit a site
• the site presents your browser with a certificate
  signed by Verisign
• your browser is confident that it knows
  Verisign's public key
• you are now confident of the site's public key
• you can now have encrypted (SSL) conversations
  with the site
• Key revocation is solved (Alice calls Verisign,
  and transactions stop)
• But this model does not support casual contact
  between individuals