1 Protocol Analysis In lecture we have looked at some different vulnerable (e.g., Diffie-Hellman, NeedhamSchroeder) and improved (e.g., Diffie-Hellman with signing, Otway-Rees) protocols. For this exercise you are analyzing two (flawed) protocols for establishing session keys and transmitting a secret value. In Part 2 you will be implementing attacks that take advantage of those flaws. Unsurprisingly, one takeaway from this assignment should be that its usually a bad idea to roll your own (crypto, protocols, etc.). 2 The Task

Youve been at Happy Happy Corporation for a few months now. You sorted out the companys problems with Alices incomplete decryption implementations. Now youre being asked to perform a few tasks as an internal red team member to look for potential vulnerabilities in ways that the company does things. Bob has designed and implemented a few different server-client protocols for establishing a shared session key. Copies of the client software get distributed to customers. The client software then sets up a shared session key (via one of Bobs custom protocols) and proceeds to use the session key to receive encrypted versions of super secret data from the server. Bobs protocols are supposed to prevent any attackers from learning the super secret data, even when an attacker is able to get their hands on a copy of the client software. Before even looking at the code, you decide to analyze Bobs custom protocols to look for potential vulnerabilities. Since you know that custom protocols are always by default suspected vulnerable, you expect to find flaws.

3 General Information

Assume that as an active adversary, you can: Run the client software to initiate its protocol with the server. 1 Eavesdrop/capture any traffic sent between the client and the server. Get the client to connect to your IP/port instead of to the real servers. Send messages to the server and intercept/receive any responses. Run sessions in parallel. You CANNOT assume: That you know or can find out any of the keys ahead of time. That you can brute force anything. Anything additional about how the encryption is performed (e.g., block cipher used, block cipher mode used). You are attacking the protocol (which messages are sent and in what order), not any particular encryption implementation. In the protocols below, || is used to denote concatenation. 4 Example Protocol You take a look at the first one of Bobs protocols and think through how an attack might work. 1. C S : SessionKey || E(Kcs0, From client) 2. S C : E(SessionKey, SecretV alue0) In this protocol, a client C and server S share a longterm symmetric key Kcs0. This key is only known to the server and client. You do not know the key. In the first step, the client chooses 32 random bytes that it would like the server to use as a temporary key. It sends those bytes to the server concatenated with the ciphertext of the string From client, which is encrypted with the shared secret key Kcs0 known only to the server and the client. The server decrypts the ciphertext and checks that it indeed is the ciphertext of From client. (If the ciphertext doesnt check out, the server closes the connection and sends no further messages.) Bob concludes that this proves to the server that the client is a legitimate copy of Happy Happy Corporations client software. In the second step, the server sends the SecretV alue0 back to the client encrypted with the SessionKey. 4.1 Example Protocol Attack

You notice that Bobs protocol has a number of flaws that would allow you to get a copy of SecretV alue0. 2 First, you notice that the SessionKey is sent from the client unencrypted; therefore, after seeing (1) and (2), you could decrypt E(SessionKey, SecretV alue0) with the plaintext copy of the SessionKey that you captured while eavesdropping. However, you notice a second attack that you find more interesting: 1. C S : SessionKey || E(Kcs0, From client) 2. M S : M allorySessionKey || E(Kcs0, From client) 3. S M : E(M allorySessionKey, SecretV alue0) After seeing the first half of a legitimate run-through of the protocol(1)you have a copy of the ciphertext produced by E(Kcs0, From client). Since that functions as the proof to the server that the client is legitimate, you can actually: (2) create a session key of your choice and send it to the server concatenated with the ciphertext you previously captured. The server then responds in (3) with the SecretV alue0 encrypted with the session key that you chose, which of course you can decrypt. It looks like the flaws in Bobs other two protocols are less obvious, but your guess is that you can use the same general ideas (and pre-existing security knowledge) to attack the other protocols. 5 Protocol A

You see that Bob distributed a different client executable to customers that uses a second (different) protocol to talk to a different server. 1. C S : E(Kcs1, SessionKey) 2. S C : nonce || E(Kcs1, nonce) || E(SessionKey, SecretV alue1) In this protocol, a client C and server S share a longterm symmetric key Kcs1. This key is only known to the server and client. You do not know the key. First, the client initiates a connection by generating a random 32-byte session key, encrypting it with the shared key Kcs1, and sending the result to the server. Second, to prove to the client that the reply really came from the server, the server generates a random 32-byte nonce and sends this to the client both in the clear and encrypted with the shared key Kcs1. The client checks that these values (nonce and the result of decrypting E(Kcs1, nonce)) are the same to ensure that the message really did come from the server. If this check succeeds, the client believes that E(SessionKey, SecretV alue1) came from the server. Note that if you, as an attacker, attempt to craft a E(Kcs1, M allorySessionKey) without knowing Kcs1, the server will either immediately be able to tell that the message did not come from the client (if authenticated encryption is being used) or the server will decrypt 3 the bytes you sent to some session key you do not know, in which case you will not be able to decrypt E(M allorySessionKey, SecretV alue1). This protocol is flawed. 5.1

To Do [12 Points] Analyze this protocol and find an attack that will let you learn SecretV alue1 from the server. Make sure that your attack is agnostic with respect to encryption method (e.g., cipher, cipher block mode). The attack can be achieved in 2 steps after seeing a legitimate protocol run-through. You will be penalized for any attacks longer than this. Describe each step of your attack using the above notation with the addition of the attacker M (see the Example Protocol Attack). You will be penalized if you use different notation.