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
participants (5)
-
Alan Horowitz
-
Chris Townsend
-
Dave Emery
-
jim bell
-
Simon Spero