# Is use of pre-shared key for sharing session key in symmetric key cryptography vulnerable to MITM?

Consider the following protocol:

Alice                    ------------------------> R1     Bob
Alice        k(R1),R2    <-----------------------         Bob
Alice                     ------------------------> k(R2) Bob
Alice         k(S)       <------------------------        Bob


Where

• k is pre-shared key, known only to Alice and Bob;
• k(x) is the encryption of x under key k
• R1 is a random number generated by Alice;
• R2 is a random number generated by Bob;
• S is the session key, generated by Bob.

Is this protocol susceptible to MITM? If yes, then how?

-
That protocol looks terrible to me –  Richie Frame Feb 19 at 9:20
Does $Pk(\dots)$ denote encryption with $Pk$ as key? Pretend you are Alice and that you have just completed a protocol run. What do you know? What can you deduce about Bob? Don't forget that you and Bob are have other instances of the protocol running in parallel. –  K.G. Feb 19 at 9:34
@K.G. Pk(...) denotes encryption with key Pk. Please note that figlesquidge has now edited 'Pk' to just 'k' now. –  user40349 Feb 19 at 18:29
Just to be clear, the protocol is obviously not secure. Alice has no security. Bob has some security, but probably not enough. The interesting part is of course finding attacks. A nice exercise. –  K.G. Feb 20 at 14:17

Obvious, but not serious weakness that numbers R1 and R2 will be sent in plain text. This means that MITM is able to modify R1 or R2 so that Alice or Bob will always be failed at authentication, although they have legal key K.

I have one suggestion how you can improve this protocol. Just because in the last step of protocol, Bob send only encrypted S, MITM can wait wile previous steps will completed successfully, and then send some old message K(S_old), where S_old is old session key, which was compromised. To avoid such danger, add number R2 to the last Bob’s response K(S,R2).

-
If an adversary modifies R1, then when alice checks K(R1) it will not match with the value expected, so Alice will know the scheme was attacked –  figlesquidge Feb 19 at 10:44
@figlesquidge indeed, but the scheme is not protected against mitm replay attacks to a certain degree, and may fall to them if crafted properly –  Richie Frame Feb 19 at 11:04
@figlesquidge Yes, you are right. –  user40349 Feb 19 at 18:31
@neverwalkaloner Well, denial of service is possible here. But I am asking about a normal MITM attack. Can you please give one such scenario. –  user40349 Feb 19 at 18:32
@user40349 I have only one suggestion how you can improve this protocol. Just because in the last step of protocol, Bob send only encrypted S, MITM can wait wile previous steps will completed successfully, and then send some old message K(S_old), where S_old is old session key, which was compromised. To avoid such danger, add number R2 to the last Bobs response K(S,R2). –  neverwalkaloner Feb 20 at 5:13

If a weak cipher is being used, it could be a possibility that an attacker could gather information about k(R1) and k(R2) and derive the k value. Following which, S could be decrypted with the derived k value. Eavesdropping could take place too. Similarly, a MITM would be possible too.

-

Under some algorithms, if you are just encrypting (not authenticating with a MAC) S may be manipulated by the adversary and thus he would be able to see all data sent from Alice (he could impersonate Bob).

-
But S is encrypted with pre-shared key k which is known only to Alice and Bob. –  user40349 Feb 19 at 18:27
Yes, but you have malleable ciphers, where you can alter the content of the message and probably recover the content. See: en.wikipedia.org/wiki/Malleability_(cryptography) –  izaera Feb 20 at 7:21
In general you should always authenticate messages when you encrypt them. There's no security when only encrypting (without authentication). Also, in your protocol, I can't see how sending R1 and R2 helps. A MITM could let R1 and R2 messages pass and then intercept subsequent communications. –  izaera Feb 20 at 7:24

A MITM could note Rn and k(Rn) from one round of this session or a previous session, then replace Bob's k(S) with k(Rn), and continue talking with Alice using Rn` as the session key.

-
Thanks for the scenario. I already deduced that as you can see in my comment to the neverwalkaloner's answer. Is it possible to compromise Bob's side? –  user40349 Feb 21 at 1:03
At least in the random oracle model, Eve won't be able to find S from k(S) unless S has been previously used as an R (or maybe as an S of a previous session). Since Bob selects S at random (presumably from a sufficiently large set), the probability that it has been previously used as an R or S should be negligible. –  Brock Hansen Mar 3 at 15:44
I.e., a MitM won't know S, so Bob just needs to require session messages have a MAC that depends on S. –  Brock Hansen Mar 3 at 15:53

Bob's side seems to be "secure", because Bob generates the session-key which is encrypted with a preshared key (which obviously is not transmitted over an insecure channel). If you dismiss the possibility the easiness of a known plaintext attack the last step saves Bob side.

This just saves the messages from Bob to Alice. For the rest of the communication a MITM-Attack could be achieved by applying a replay attack or just changing the last mesage of the protocol.

-