Authenticated Key Exchange

Lecture Outline Examples… Wide-Mouthed Frog Needham-Schroeder 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 We’ll end with a brief look at Kerberos

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!

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

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 Don’t 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! Don’t 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!

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!

Failure in the Wide-Mouthed Frog Protocol Let’s 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?)

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

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!

Time, Time! Who’s 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 can’t 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

Time, Time! Who’s 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.

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 MIT’s 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.

Overview of Kerberos Trent Cliff Grant Serge This slide borrowed from Stallings.

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

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 Cliff’s 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

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 Cliff’s identity and the freshness of the authenticator. Serge to Cliff: The service is provided and protected using KCS.