Time codes for PCs (fromn German Banking)

-----BEGIN PGP SIGNED MESSAGE-----

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.

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.) 

While I've never taken the time to connect it to my PC, it provides 
(through an RS232 jack) correct time with a rated accuracy of about 5 
milliseconds, as I vaguely recall. (Even has a dipswitch setup on the bottom 
to tell it how many 500 mile increments you are away from WWVB... corrects 
for delay to a first order of magnitude.)

(BTW, if anybody knows how to easily connect it to the pc, or has the 
appropriate software, please tell me  The task isn't difficult from a 
hardware standpoint; it's just RS-232 serial ASCII timecode at about 9600
bps which 
either continuously retransmits or on request.  The problem is the software: 
 How, exactly, do I INTERFACE such a serial input to the existing computer/RTC 
combination? (Don't tell me to plug it into an unused serial jack!  I'm not 
stupid. I'm not a  programmer, and I don't play one on TV! (I know 
gates, flops, op amps, A/D, D/A, microprocessor hardware design, even some 
Z-80 assy language, RF,  and I've programmed in Fortran, Basic, APL, Algol, 
PL/1, Pascal, LISP, but not recently and I don't enjoy it!)


(Then again, there are those "Receptor" watches which have (at least) similar 
accuracy, which as I understand it work on FM subcarrier principles.)


Technology has now supplanted this old monstrosity:  Even with CHEAP GPS 
receivers, they put out time which is rated in accuracy to well better than 
1 microsecond, and probably better than 200 nanoseconds even with S/A turned 
on, and probably 100 nanoseconds with S/A off.  Once GPS receivers contain 
equally cheap DGPS receivers, they'll be able to tell you your location to 
about 1 meter and corresponding time accuracy, about 3 nanoseconds.

I'm not particularly familiar with TV VIR signals, but I'd imagine they are 
timecoded, or at least they COULD be without a lot of effort.  Resolution 
would be FAR better than 1 microsecond, and accuracy would be primarily 
limited by knowledge of your location compared to the xmitter.

MITM attacks would be far more difficult if both ends of the data 
conversation agreed on the "exact" time, and could detect transmission 
delays and CHANGES in transmission delays.  While it would be possible to 
locally spoof the accurate timecode, a cheap version of a "disciplined 
oscillator" (which any GPS receiver is going to have, anyway) would detect 
such short-term spoofing trivially.

Occasionally, I've speculated on whether it might be useful to be able to 
synchronize (or, at least, KNOW) to the PHASE of the 60 Hz power grid.  
True, I know that the HV grid is 3-phase and most people won't know which 
phase they're on anyway, but that wouldn't change (at least not frequently!) 
, and I would imagine that 
it might be  useful.  You wouldn't necessarily know which CYCLE you're on, 
either, but again that might be compensated for somehow.  If  your computer 
were talking, locally, to another computer at 4100 baud (? whatever) (7 bits 
per symbol(?); equals 28.8kbps) you could "easily" agree on a particular cycle 
relationship, which is going to be essentially constant over a distance of a 
few tens or even hundreds of miles.

What I DON'T know (and some HV transmission engineer will probably be able 
to tell me, hint hint!) is how STABLE this phase is across the entire 
country?  I realize that this will probably depend on who'se shipping excess 
 power to whom at the moment, But I'd imagine the variability will be 
distinctly limited.

The biggest attraction of such a system is that the interface would probably 
be trivial:  Getting it from the P/S is out because they didn't anticipate 
such a thing.  The easiest interface might be an AC wall xformer with a 
rectifying limiter and slicer  (Okay, maybe just a resistor and a diode, 
possibly with the addition of a comparator for precision), driving a 
readable pin on an otherwise-unused RS-232 interface.  (Possibly 
installed similar to a dongle.)  Appropriate software (yucch!) would read 
the square waves, and record the phase at any one time.  Such information 
could be used to verify the relative synchronization between two different 
computers, although it would be necessary to identify particular phases, as 
I mentioned before.


BTW, if you're read this far, I think it would be appropriate to introduce 
myself, despite the fact that I've already been posting to this area for a 
few weeks.  I'm James Dalton Bell (yes, THOSE Daltons!) and I'm in 
Vancouver, Washington, USA.  I may talk like a EE, but am not; I have formal 
and/or informal backgrounds in Chemistry (BS Chemistry MIT 1980), 
electronics (analog and digital and RF (N7IJS) and uP), physics, and keep an 
eye on numerous other technical fields.

Politically, I'm 120/120 on the Nolan chart (there's some questions they 
left out (that's a joke)) which means I'm a "extremist libertarian."  I'm 
also rather newly anarchistic, and (with all due modesty) rather inventive.  

Current employment?  None. Well, nothing to speak of.  But you'll be hearing 
more about me.

Jim Bell

Klaatu Burada Nikto   Remember this.  It'll become important, soon.

"Something is going to happen.  Something....wonderful!"






 

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMQlyv/qHVDBboB2dAQHZvQP+IKeO508C7ZTA22DSELjvpWTYa0iGtTcX
U486t+8P0iC9qxq346wzxm9USae4d8NOM9wBKrio095hrKnzAZQE1BETUKCx3BJv
bywqin7Qjb87j6OECJ6S/eAh5t6LXMnDepGdUr7rw+gBxsNg7kzz10/TGh4pXKNu
D5PuGPnTY34=
=r4JO
-----END PGP SIGNATURE-----

You are laboring under false ipression if you think it is easy to keep 
synched to an outside source to closer than, say, a millisecond. It isn't 
a turnkey deal. Cesium-beam clocks and GPS constellations notwithstanding.

Alan Horowitz
alanh@norfolk.infi.net

On Fri, 26 Jan 1996, jim bell wrote:

> (BTW, if anybody knows how to easily connect it to the pc, or has the 
> appropriate software, please tell me  The task isn't difficult from a 
> hardware standpoint; it's just RS-232 serial ASCII timecode at about 9600
> bps which 
> either continuously retransmits or on request.  The problem is the software: 
>  How, exactly, do I INTERFACE such a serial input to the existing computer/RTC 
> combination? (Don't tell me to plug it into an unused serial jack!  I'm not 
> stupid. I'm not a  programmer, and I don't play one on TV! (I know 
> gates, flops, op amps, A/D, D/A, microprocessor hardware design, even some 
> Z-80 assy language, RF,  and I've programmed in Fortran, Basic, APL, Algol, 
> PL/1, Pascal, LISP, but not recently and I don't enjoy it!)

You'll probably want to look at the XNTP code at

ftp://louie.udel.edu/pub/ntp

There's plenty of good toys and code for time geeks, radio clock
info, etc.

-cpt
townsend@fly.net

On Fri, 26 Jan 1996, Chris Townsend wrote:

> There's plenty of good toys and code for time geeks, radio clock
> info, etc.
> 

Talking about which... anybody know of any fuzzballs that are set to be 
junked? It'd be cool to take a fuzzball and get IPV6 w/IPSEC running. 
Wouldn't like to run an OC12 through it though.

> 
> -----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
>

> 
> 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.

	The only technology that I'd trust to be useful much below
10-100 ms is GPS.   The others are unlikely to be controlled well enough
at the source to be trusted.  Current TV broadcasting, for example,
usually involves multiple passes though digital frame stores and time
base correctors  - most homes get the signal via cable which itself
involves significant uncontrolled delays  (juat the thermal changes
in propagation delay  in a long CATV cable and amplifier chain due to weather
changes run into the many microseconds).

	And humans beings being as imperfect as they are, it is hard to
beleive that making sure that the time being broadcast is really kept accurate
is going to be a priority when most people use it for purposes that require
plus or minus a few seconds timing.

> 
> 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.) 
> 
> While I've never taken the time to connect it to my PC, it provides 
> (through an RS232 jack) correct time with a rated accuracy of about 5 
> milliseconds, as I vaguely recall. (Even has a dipswitch setup on the bottom 
> to tell it how many 500 mile increments you are away from WWVB... corrects 
> for delay to a first order of magnitude.)
> 
	WWVB is the 60 khz broadcast (which is more accurate due to more
stable propagation) . the  HF ones are WWV.  Commercial time receivers
are available that work off the 60 khz time code (very narrow bandwidth
ASK), but the 60 khz is most used as a standard frequency for long
term tracking of error in local standards.

> (BTW, if anybody knows how to easily connect it to the pc, or has the 
> appropriate software, please tell me  The task isn't difficult from a 
> hardware standpoint; it's just RS-232 serial ASCII timecode at about 9600
> bps which 
> either continuously retransmits or on request.  The problem is the software:

	If you run unix there are some quite sophisticated programs that
can use this specific clock (connected to a serial port) that allow sync
to the full accuracy possible at good times of day (around 1 ms).   The
programs also allow time distribution to other computers on a network -
thus their name  - ntp - which stands for network time protocol (and the
network time program that implements it). This protocol and the various unix
programs that implement it are quite widely used on commercial LANs and
the Internet to sychronize time amoung unix workstations, servers, and
bridges and routers.  Current implementations are capable of tracking
clock oscillator error on a system and adjusting the time periodically
to compensate for the frequency error of the clock and even to predict
(polynomial approximation) the change in frequency error with time.

	The man behind much of this (at least the early research) is
Dave Mills who used to be at louie.udel.edu which hosted a ftp
site for the programs.   An archie search will reveal where they
are kept now, and there is a newsgroup (comp.protocols.time.ntp) for this
which no doubt has a substantial faq file about this. 

	
>  How, exactly, do I INTERFACE such a serial input to the existing computer/RTC 
> combination? (Don't tell me to plug it into an unused serial jack!  I'm not 
> stupid. I'm not a  programmer, and I don't play one on TV! (I know 
> gates, flops, op amps, A/D, D/A, microprocessor hardware design, even some 
> Z-80 assy language, RF,  and I've programmed in Fortran, Basic, APL, Algol, 
> PL/1, Pascal, LISP, but not recently and I don't enjoy it!)
> 
> 

	I suspect that by this point there are several windoze/DOS  programs
to sync a PC to ntp time on a network, and perhaps even a program that will 
accept input from a Heath clock ... although the initial ntp code was
written for unix on Suns.
\

> (Then again, there are those "Receptor" watches which have (at least) similar 
> accuracy, which as I understand it work on FM subcarrier principles.)

	Yes they use the RDS broadcast on the 57 khz subcarrier for this.
Of course there is no certainty the station has the clock set accurately.
> 
> 
> Technology has now supplanted this old monstrosity:  Even with CHEAP GPS 
> receivers, they put out time which is rated in accuracy to well better than 
> 1 microsecond, and probably better than 200 nanoseconds even with S/A turned 
> on, and probably 100 nanoseconds with S/A off.  Once GPS receivers contain 
> equally cheap DGPS receivers, they'll be able to tell you your location to 
> about 1 meter and corresponding time accuracy, about 3 nanoseconds.
> 
	Yup.   And ntp can use several cheap gps products available to sync
a unix clock to high accuracy.

> I'm not particularly familiar with TV VIR signals, but I'd imagine they are 
> timecoded, or at least they COULD be without a lot of effort.  Resolution 
> would be FAR better than 1 microsecond, and accuracy would be primarily 
> limited by knowledge of your location compared to the xmitter.
> 
	Could be is the operative word here,  Many tv program
distribution signals carry frame time codes in the VIT, but who put them
there, how accurately they reflect local time  and where in the delay
chain (before or after the satellite for example) they get inserted is
not well controlled.   Nor is there a standard for the format that
addresses the needs of end users rather than broadcast production, or
any particular effort to ensure that a signal is reliably present in the
over the air transmission.

	Once many years ago (seventies)  the NBS (not NIST yet) tried to
get the TV networks to clock themselves with high accuracy rubidium
standards as a means of distributing standard frequency and time. But
technology has made this meaningless as most tv signals are now
distributed via satellites that move around several kilometers in a day
and clocked into multiple layers of frame stores (often delayed more
than a second)  in digital switching and processing gear and clocked out
with different clocks that often are not very accurate and not in any
way locked to the incoming network.

	TV stations could be made to maintain a local clock sync'd to
GPS and use that to do the final level of clocking out before feeding
the transmitter and could thus ensure that some reference point in some
frame happened at an exact time, but given that a user who can see a TV
signal can probably see GPS signals and can do the same timekeeping himself
for a couple hundred bucks it hardly seems worth it any more.  I do
expect that time codes with modest accuracy (few tens of ms at best)
will become common as part of the Starsite (or whatever they call it
now) program guide distribution on PBS, simply because this has defined
a format that can conveniantly contain time messages multiplexed with
other data and the box displays the time.  DSS and VC-II both also have
this capability, but of course the uncertainty of the satellite delay
limits accuracy and neither has provisions for providing time to other
devices.


> MITM attacks would be far more difficult if both ends of the data 
> conversation agreed on the "exact" time, and could detect transmission 
> delays and CHANGES in transmission delays.  While it would be possible to 
> locally spoof the accurate timecode, a cheap version of a "disciplined 
> oscillator" (which any GPS receiver is going to have, anyway) would detect 
> such short-term spoofing trivially.
> 

	See my public comments on this.



> Occasionally, I've speculated on whether it might be useful to be able to 
> synchronize (or, at least, KNOW) to the PHASE of the 60 Hz power grid.  
> True, I know that the HV grid is 3-phase and most people won't know which 
> phase they're on anyway, but that wouldn't change (at least not frequently!) 
> , and I would imagine that 
> it might be  useful.  You wouldn't necessarily know which CYCLE you're on, 
> either, but again that might be compensated for somehow.  If  your computer 
> were talking, locally, to another computer at 4100 baud (? whatever) (7 bits 
> per symbol(?); equals 28.8kbps) you could "easily" agree on a particular cycle 
> relationship, which is going to be essentially constant over a distance of a 
> few tens or even hundreds of miles.
> 
	This is possible, but I bet the variations in phase in the local
distribution system due to power factor, choice of phase to use, propagation
time through transmission lines and substations and so forth would
mean that phase as observed at two distant sites was rather random
and maybe even subject to shifts over time as load conditions varied.

> What I DON'T know (and some HV transmission engineer will probably be able 
> to tell me, hint hint!) is how STABLE this phase is across the entire 
> country?  I realize that this will probably depend on who'se shipping excess 
>  power to whom at the moment, But I'd imagine the variability will be 
> distinctly limited.
> 
	I've seen some discussions about this, but don't know a reliable
answer.  I do know that the frequency is only 60 hz on the average over
a day and actually wanders up and down quite a bit more than one might
expect as load on the system varies.  I did some measurements of this 22
years ago while debugging some PDP-8E system software I wrote that that
ran a frequency counter (the ratio kind that was very accurate on low
frequencies) and found the diurnal variations surprisingly large and
quite interesting.  I've not repeated the experiment since but suspect
that they still allow the frequency to wander in response to load conditions.

> The biggest attraction of such a system is that the interface would probably 
> be trivial:  Getting it from the P/S is out because they didn't anticipate 
> such a thing.  The easiest interface might be an AC wall xformer with a 
> rectifying limiter and slicer  (Okay, maybe just a resistor and a diode, 
> possibly with the addition of a comparator for precision), driving a 
> readable pin on an otherwise-unused RS-232 interface.  (Possibly 
> installed similar to a dongle.)  Appropriate software (yucch!) would read 
> the square waves, and record the phase at any one time.  Such information 
> could be used to verify the relative synchronization between two different 
> computers, although it would be necessary to identify particular phases, as 
> I mentioned before.
> 
	One could certainly do this, but there are subtlies ... some
places and institutions generate their power locally (and few if any
users know this or know whether or not they are on the grid), UPS
systems are common and wander off of the grid during a power fail,
and many buildings have all three phases floating around wall outlets,
even wall outlets close to each other so such acts as moving plugs
around might very well change the phase.  And power systems switch
phase correction capacitors in and out from time to time as power
factor of large loads varies.  My guess is that to synchronize much
below a ms would be hard, and that random losses and jumps of sync would be
common enough to require lots of special treatment in software.

						Dave Emery  N1PRE
						die@die.com