3

I am trying to find attacks on a theoretical protocol or prove its security. An initiator wants to establish a shared key with a responder with help of a trusted server.

We have the following roles: $I$: Initiator, $R$: Responder, $S$: Server.

There are long-term symmetric keys between all pairs of involved entities denoted by $k(X,Y)$.

The protocol involves some nonces:

  • $\mathrm{sid}$ and $n_I$ are generated by $I$.
  • $n_R$ is generated by $R$.
  • A session key $\mathrm{sesskey}$ is generated by $S$ at every execution.

The message $m$ encrypted with the key $k(X,Y)$ is written as $\{m\}_{k(X,Y)}$.

Goal: The key $\mathrm{sesskey}$ should be secretly shared between $I$ and $R$. $S$ is trusted, and is also allowed to know $\mathrm{sesskey}$.

Adversary model: Dolev-Yao. The adversary knows all entity names at beginning.

Protocol: $$ \begin{array}{rcl} 1. & I \to S : & \mathrm{sid}, \: I, \: \{n_I, \mathrm{sid}, I, R, S\}_{k(I,S)} \\ 2. & I \to R : & \mathrm{sid}, \: I \vphantom{\{\}_{k()}} \\ 3. & R \to S : & \mathrm{sid}, \: R, \: \{n_R, \mathrm{sid}, S, I, R\}_{k(I,R)} \\ 4. & S \to R : & \mathrm{sid}, \: \{n_R, \mathrm{sesskey}\}_{k(R,S)} \\ 5. & S \to I : & \mathrm{sid}, \: \{n_I, \mathrm{sesskey}\}_{k(I,S)} \\ \end{array} $$

Now what I have found so far is that if we assume $\mathrm{len}(\mathrm{sid},I,R,S) = \mathrm{len}(\mathrm{sesskey})$ then we can easily break the protocol with a type-flaw attack as follows. Impersonate $S$ and send $\mathrm{sid}, \{n_R, \mathrm{sid}, S, I, R\}_{k(I,R)}$ to $R$ in step 4, and $\mathrm{sid}, \{n_I, \mathrm{sid}, I, R, S\}_{k(I,S)}$ to $I$ in step 5. We thereby construct two session keys $(\mathrm{sid}, S, I, R)$ and $(\mathrm{sid}, I, R, S)$ for $R$ and $I$. We can thereafter intercept and forward (encrypting with one and decrypting with the other key) all communication between $I$ and $R$.

However, I find this unsatisfactory because we impose assumptions on the length of $\mathrm{sid}$, the names and the session key. It is not leaving my mind, but I cannot find any other attack. Can you prove the security of this protocol or do you see a different possible attack?

Gilles 'SO- stop being evil'
  • 19,134
  • 4
  • 50
  • 92
  • 2
    Is this homework? – Lucas Kauffman Jul 25 '13 at 16:24
  • @Lucas Kauffman: It is an exam question. I was not sure whether it is welcome here, but could not find an entry in the faq saying it wasn't. Since I think it is an interesting question I hope it is still appreciated. –  Jul 25 '13 at 16:33
  • Can the one downvoting please explain why this is not a good question? –  Jul 25 '13 at 18:06
  • The single character variable notation makes me not want to try understanding this. If it takes me more than a few seconds to decide whether this is a protocol question or a crypto question, you're not being sufficiently clear. – Jeff Ferland Jul 25 '13 at 18:29
  • @JeffFerland: "Can you prove the security of this protocol or do you see a different possible attack?" Is the only phrase with a question mark. It is clearly stated that I am asking about the security of the protocol. Also would it not make any sense to ask for a cryptographic attack since I am not giving any details on the types of encryption used. Just so that I can improve on a next question, could you please let me know what is wrong with this question? –  Jul 26 '13 at 07:06
  • 1
    do you really want k(I,R) in step 3? Or k(R, S)? – CodesInChaos Jul 28 '13 at 19:34
  • 1
    What properties does your encryption provide? Is it authenticated encryption? Is it malleable? What about proper IVs? – CodesInChaos Jul 28 '13 at 19:38
  • Can the adversary communicate with S using their own identity E? If you combine that with an unauthenticated stream cipher as encryption you'd get another vulnerability. – CodesInChaos Jul 28 '13 at 19:54
  • 1
    @CodesInChaos Normally in this kind of formal analysis of crypto protocol, the encryption is considered as a magic enveloppe. If you instantiate it with real-life crypto, you should use authenticated encryption. I agree with your $k(R,S)$ comment in step 3. I think that the expected problem with this protocol is that an attacker that intercepts and replays messages can dupe $S$ into believing that $R$ is the initiator and $I$ the responder. – minar Jul 28 '13 at 19:55
  • @minar One problem with this description is that it doesn't describe what the parties do with the messages they receive. For example if the server validates that $S$ is in the expected place in the message then it can distinguish message 1 from message 3. It's also not clear to me why it'd be a problem if $S$ mixes up $I$ and $R$ since it'd still send them a proper session key. | Analyzing real protocols is certainly much nicer than analyzing underspecified theoretical protocols :) – CodesInChaos Jul 28 '13 at 20:06
  • @CodesInChaos Yes, this is ugly and I rather dislike this kind of specifications. The reason some people are using this is that in this framework, they can use automated tools to find the weaknesses. Thus, these examples are often used as benchmarks for automated proofs. – minar Jul 28 '13 at 20:15
  • @CodesInChaos You can find an example here: http://www.irit.fr/~Yannick.Chevalier/ChevalierV-VerifWS.pdf – minar Jul 28 '13 at 20:21

0 Answers0