Authenticated Key Exchange

1
Authenticated Key Exchange
2
Lecture Outline

• Example of how poor security design can cause
  problems
• Design Principles for building security protocols
• Key tools for building robust security protocols
• Naming
• Encryption
• Signing
• Timestamps and nonces
• Examples
• Wide-Mouthed Frog
• Needham-Schroeder
• Well end with a brief look at Kerberos

3
Tales from the Dark Side of Security

• Pay-Per-View TV Hacks
• Decoders are personalized with a smart card.
  Smart card cannot decrypt bulk content, so the
  bulk decryption is done on the decoder.
• Many decoders have a microcontroller which passes
  messages between the cryptoprocessor and the
  smart card
• Attackers can go in and modify or replace the
  microcontroller, or can introduce a PC between
  the decoder and the card in order to manipulate
  messages exchanged.
• Kentucky Fried Chip hack
• When a customer stops paying subscription, the
  system sends a message to the decoder to disable
  the card.
• The KFC hack replaced the microcontroller with a
  a version that would block this message.
• It was able to do this because the system message
  was sent in the clear!

4
Caveat Cryptor Designer Beware!

• The lesson learned from this last story is The
  adversary can be very powerful and clever!
• We must assume that the adversary has complete
  control over the network
• Be paranoid! Alice should not blindly trust what
  she is getting from Bob! And vice-versa!
• If we can build a system that we trust in this
  Seriously Caustic environment, then we can trust
  it in more general (day-to-day) computing
  scenarios
• So, who are the entities?
• Alice and Bob may be users, or may be smart
  cards, or devices
• Eve can be the compromised decoder, or the
  network, or a hacker
• When needed, Trent will be a trusted third party
  server

5
Basic Guidelines

• Needham has given several guidelines for building
  secure systems
• Be clear of security goals and assumptions
• When using encryption, know why you are using it
  (secrecy? Authenticity? Binding? PRNG?) .
  Encryption is not security!
• Be careful about temporal associations
• Dont assume the identity of a participant can be
  excluded from a message. Generally, it should be
  explicitly included in a message!
• Have redundancy in your message!
• Know the properties and weaknesses of the
  cryptographic protocols you are using.
• Signatures do not imply that the signer knows
  what the message is that he is signing!
• Dont trust others to keep their secrets secret!
• When responding to queries, be careful about
  encrypting, decrypting, or signing. You might be
  used as an oracle by an adversary!
• Decryption is not the same as digital signatures-
  they have different purposes!
• Distinguish between different runs of the
  protocol!

6
Wide-Mouthed Frog Protocol

• The Wide-Mouthed Frog Protocol is one of the
  simplest symmetric key management protocols
  involving a trusted third party (Trent T)
• Alice chooses a session key to communicate with
  Bob and has Trent transfer it to Bob securely.
• The parameter tA is a timestamp supplied by
  Alice, while tT is given by Trent. Bob will
  accept KAB as fresh if it arrives in a certain
  window of time.
• The WMF protocol fails because Trent updates the
  timestamp
• If Trent does not keep a list of all recent keys
  and timestamps, Eve can use Trent as an Oracle!

7
Failure in the Wide-Mouthed Frog Protocol

• Lets see how Eve can make Trent act as an
  Oracle
• After seeing one exchange of the protocol, Eve
  could pretend to be Bob wanting to share a key
  with Alice
• Eve would send Trent the replay
• Trent would send back
  , where is a new timestamp.
  Alice would think this is an OK message since it
  came from Trent.
• Eve could then pretend to be Alice and get
• And so on
• Effect The key KAB is kept indefinitely alive
• To fix You need to be explicitly clear about how
  you keep track of temporal succession (did you
  see this key before?)

8
Needham-Schroeder

• We now look at the Needham-Schroeder
  authenticated key exchange protocol
• The protocol

Step 1 Alice tells Trent what she is
requesting Step 2 Trent gives Alice the session
key and gives Alice a package to deliver to
Bob. Step 3 Bob can get the session key, and the
identity of who he is talking with (verified
because it came from Trent). Step 4 Bob sends
Alice a challenge Step 5 Alice answers challenge
9
An attack on Needham-Schroeder

• In 1981, Denning and Sacco showed if the session
  key is compromised, then Eve can make Bob think
  that he is communicating with Alice.
• Assume the NS protocol took place, and that Eve
  has recorded the first 3 steps. Also, assume that
  Eve has obtained the session key.
• The following steps subvert NS

Step 1 Eve replays step 3 from NS as if she were
Alice. Step 2 Bob gets this message and issues
a challenge to Alice in the form of a new nonce.
This challenge is intercepted by Eve. Step 3
Since Eve knows the session key, she can respond
correctly to the challenge. The basic problem
messages can be replayed once the session key is
compromised!
10
Time, Time! Whos got the Time?

• The clock plays an important role in many
  security protocols.
• Time provides an ordering of events
• Time and timestamps help provide measures of
  freshness to protocols
• Having reliable and synchronized clocks is an
  important challenge in building secure and
  trusted systems.
• We cant simply use the normal clock time an
  enemy may manipulate the clock, or the clock may
  fail
• Setting the clock back
• Perhaps a user had access to some data in the
  past, but that access has expired now. Setting
  the clock back might allow the user to access
  data for which his access privileges had expired.
• Expired certificates are fresh again
• Automated tasks may be forced to repeat by
  repeatedly setting the clock back after the task
  is executed

11
Time, Time! Whos got the Time? Pg. 2

• Stop the time
• An adversary may freeze the clock and thereby
  cause audit logs to become ambiguous
• Actions, such as refreshes, no longer happen.
• Setting the clock ahead
• Denial of service attacks are possible
  Certificates automatically expire!
• Many situations involve release of confidential
  information at a specified time in the future
  moving the clock ahead forces the release of this
  information!
• In auction-based systems, if you can alter the
  auction-system clock forward, you can deny many
  rivals the opportunity to get last-bids in.

12
Kerberos

• Kerberos is a real-world implementation of a
  symmetric cryptographic protocol that provides
  authentication and security during key exchange
  between users in a network.
• It is, basically, a real-world implementation of
  Needham-Schroeder with some appropriate fixes.
• Kerberos grew out of MITs Project Athena, whose
  purpose was to integrate a network of computer
  workstations and allow students to access files
  easily from anywhere on the network.
• Kerberos is based upon a client-server model.
• Actors
• Cliff The Client, wants to use a service
• Serge The service server
• Trent A Trusted Authority (also called an
  Authentication Server)
• Grant Ticket Granting Server
• There are two versions of Kerberos in use
  (Version 4 and Version 5). We will discuss the
  basics common to them both.

13
Overview of Kerberos
Trent
Cliff
Grant
Serge
This slide borrowed from Stallings.
14
Basic Kerberos Steps

• The basics of the protocol
• Cliff to Trent Request to Trent for help in
  authenticating with the Ticket Granting Server
  (Grant)
• Trent to Cliff Trent looks Cliff up. If Cliff is
  OK, Trent generates a session key KCG for use
  between Cliff and Grant. This is encrypted using
  KC. Trent also creates a Ticket Granting Ticket
  (TGT) that will allow Cliff to authenticate
  himself to Grant

15
Basic Kerberos Steps, pg. 2

• The basics of the protocol
• Cliff to Grant Using KCG, Cliff can now
  communicate with Grant. Cliff creates an
  authenticator message and sends AuthCG as well as
  TGT to Grant
• Grant to Cliff Grant gets AuthCG and TGT. Grant
  uses his secret key to recover Cliffs name, etc.
  Grant uses KCG to decrypt AuthCG to verify
  authenticity of AuthCG. If the names match, and
  the timestamps are sufficiently close, then Cliff
  is valid. Grant creates a service ticket
  (encrypted with a key Grant shares with Serge).
  Grant sends ServTicket and encrypted KCS to Cliff
  

16
Basic Kerberos Steps, pg. 3

• The basics of the protocol
• Cliff to Serge Cliff now contacts Serge to use
  his services. He gets KCS, which he will use when
  communicating with Serge.
• He creates an authenticator AuthCS.
• Cliff sends Serge AuthCS and ServTicket.
• Serge can decrypt ServTicket and get KCS.
• Using KCS he can decrypt AuthCS and verify
  Cliffs identity and the freshness of the
  authenticator.
• Serge to Cliff The service is provided and
  protected using KCS.