From: "Dave Emery" <die@pig.die.com>
Date: Sat, 27 Jan 1996 12:26:06 +0800
To: jimbell@pacifier.com (jim bell)
Subject: Re: Time codes for PCs (fromn German Banking)
In-Reply-To: <m0tfyb0-00090XC@pacifier.com>
Message-ID: <9601270353.AA07828@pig.die.com>
MIME-Version: 1.0
Content-Type: text/plain


> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Jim Bell wrote:

> At 11:11 PM 1/24/96 -0500, Dave Emery wrote:
> >> 
> >> Was the person in the basement eavesdroping or actuall performing a
> >> man-in-the-middle attack?
> >> 
> >	Very much the easiest way of doing this is a classic man in the
> >middle attack with two vanilla off the shelf modems and a vanilla off
> >the shelf central office simulator.  The modems would be  tied more or
> >less back to back through two serial ports and software on a laptop in
> >the basement, one modem connected to the actual phone line to the central
> >office and the other connected to the local wires to the targets home
> >through the central office simulator.  This way all traffic in both
> >directions would go through the modems and software on the laptop
> >allowing the connection to be taken over cleanly between packets, and
> >packets to be injected and deleted as needed.  I beleive that it would
> >not be hard to make such a MITM decode the DTMF dialing from the target 
> >and dial the same number on its outgoing modem thus enabling the
> >MITM to passively relay modem calls it wasn't interested in spoofing.
> >And incoming modem calls could be similarly handled.
> 
> A peripheral I've long wanted to see, commonly available:  ACCURATE  time, 
> broadcast to the millisecond/microsecond/nanosecond, available from sources 
> as varied as TV VIR's, FM subcarriers, and other sources, available as an 
> easy input (via a peripheral card) to a computer.

	Unfortunately even if the special software, delay checking protocols 
and accurate time distribution to suppport this was widely distributed
around the net (which is a huge if) this would not do much against the
kind of MITM I've hypothesized in many real world modem situations.   The
propagation delay of the telephone network (particularly inter-LATA long
distance) can vary considerably as calls can be routed via all sorts of
paths including some involving large detours - the delay through the
MITM would certainly be detectable but not necessarily obvious compared
to the variability in telco network timing (and circuit quality) from
call to call.

 	Also the delay through modems is quite variable depending on who
wrote the firmware (eg the modem brands on both ends of the link), what
speed and signalling parameters the modem has negotiated, whether or not
compression is enabled (and how compressable the data is) and what
parameters for it are selected, and how good the line is. The last is
very important, on a poor line with ARQ error control enabled LAPM
packets may be retransmitted more than once adding intermittant longer
delays and from time to time retraining may occur adding even longer
delays.

	This would make establishing alarm limits for delay that
would trip on the hypothetical MITM reliably and not go off on random
variations from connection to connection very difficult.

	And one does not need accurate time of day to measure link
propagation times - if one is running TCP/IP or most varients of it
there is a built in low level echo function (the ICMP echo, used by the
unix ping command and traceroute) that allows one to send a packet and
get back an (usually) immediate echo from each router in the path and
the path endpoint.  If one is running plain VT100 type in, the character
echoing is usually done promptly by the host and echo delays can be
measured as one types  and gets back characters.

	Worst case is running some sort of vanilla ASCII text (VT100) 
or proprietary binary protocol via a dial in X.25 or similar PAD (such
as provided by Compuserve, Prodigy and Netcom for most of their
dial-ins).  Here most or all echoing is via the providers network from a
distant host and may be both long delayed  compared to MITM delays and
quite variable due to network loading.

	There is some glimmer of hope, however with current crop of V.34
(28.8kb)  modems, most of them have commands to report the link analog
characteristics and one of the standard reported items is the delay to
the far end modem. If this is almost 0 ms for a call to the other coast
one can and should get very suspicous.   Unfortunately, a more
sophisticated MITM  that would defeat this check than the one I
hypothesized could be built using a vanilla stereo sound card to add
appropriate delay by digitizing the line signal and delaying it in
memory before spitting it out the other channel to the local listening
modem.

	Perhaps the best defense for the paranoid is to make sure that
all the obscure low speed modes, voice calls on the line,  and things
like fax tranmission work reliably and as they should - but even this
can be defeated with a slight increase in MITM sophistication, and in
any case this kind of MITM is presumably targeted at hit and run attacks
on the unsophisticated who would presumably not know how to check for
this stuff. 

	All of this just emphasizes the need for strong message
authentication best done with crypto technology, and for secure end to
end encryption of virtual circuits used by many common  character by
character (such as telnet and VT-100 connections)  or packet by packet
transactions that use authentication only done up front (avoiding the
hijacking problem where the link is authenticated by something at the
beginning of the session such as a password or challenge/response
protocol and then taken over (perhaps only momentarily) by an intruder).
 
> 
> I have a 12-year-old Heathkit "Most Accurate Clock" that I assembled myself, 
> and had the foresight to install it with its computer  interface option. 
> (receives 5, 10, or 15 MHz signals broadcast from Boulder, Colorado, 
> containing "exact" time.) 

	I have some more comments on time I'll send you in email as they
are (worse) noise to the list....

						Dave Emery 
						die@die.com
>