Interlock Protocol - Forced-Latency Interlock Protocol

Forced-Latency Interlock Protocol

A modified Interlock Protocol can require B (the server) to delay all responses for a known duration:

A B Ka-------------> <-------------Kb Ea,b(Ma)<1>----> <----Ea,b(Mb)<1> (B delays response a fixed time, T) Ea,b(Ma)<2>----> <----Ea,b(Mb)<2> (delay again) <----------data)

Where "data" is the encrypted data that immediately follows the Interlock Protocol exchange (it could be anything), encoded using an all-or-nothing transform to prevent in-transit modification of the message.

MITM can be attempted using the attack described in the Bellovin paper (Z being the man-in-the-middle):

A Z B Ka------------->Kz-------------> <------------------> <--------------Ea,z(Mz)<1> (delayed response) Ea,z(Ma)<2>----> <--------------Ea,z(Mz)<2> (delayed response) Ez',b(Ma)<1>----> <----Ez',b(Mb)<2> (delayed response) Ez',b(Ma)<2>----> <----Ez',b(Mb)<2> (delayed response) <-------------data <---------data

In this case, A receives the data approximately after 2*T, since Z has to perform the interlocking exchange with B. Hence, the attempted MITM attack can be detected and the session aborted.

Of course, Z could choose to not perform the Interlock Protocol with B (opting to instead send his own Mb) but then the session would be between A and Z, not A, Z, and B: Z wouldn't be in the middle. For this reason, the interlock protocol cannot be effectively used to provide authentication, although it can ensure that no third party can modify the messages in transit without detection.

Read more about this topic:  Interlock Protocol