Re: [time-nuts] Measuring GPS noise floor (sort of)

[Ulrich Bangert]

Mark,

what you are doing is not wrong but must be interpreted in the correct way.
Please keep in mind that you are NOT comparing two naked GPS receivers. In
fact you are comparing the outputs of two GPSDOs. The deeper sense of a
GPSDO is to surpress the noise floor of the GPS receiver as good as
possible. 

What you may get as a result out of your test is a sense of the overall
stability of your sources, not the GPS noise floor. With an AD of 1E-10 @ 1
s I fear however that you are currently measuring mainly the noise floor of
your counter. Can you give us a clue what instrument you are using?

Best regards
Ulrich 

> -Ursprungliche Nachricht-
> Von: time-nuts-boun...@febo.com 
> [mailto:time-nuts-boun...@febo.com] Im Auftrag von Mark Spencer
> Gesendet: Sonntag, 2. Dezember 2012 23:38
> An: time-nuts@febo.com
> Betreff: [time-nuts] Measuring GPS noise floor (sort of)
> 
> 
> I'm wondering how useful it is to compare two different GPS 
> receivers to a single Rb to get a sense of the GPS noise 
> floor.   I've been collecting some data for the last week or 
> so seem be making some headway with this.
> 
> Not having a cesium or an Hmaser I elected to compare two 
> different GPSDO's to a single Rb and then assuming the data 
> seemed sane, I thought I would then compute the Adev between 
> the two GPSDO's.   My assumption is that by comparing the two 
> GPSDO's to the Rb it should be possible to detect when one 
> GPSDO is mis behaving or possibly when the Rb mis behaves.  
> So far other than a bit of a glitch at the start of the 
> process things seem to be proceeding as I expected.   I hope 
> to collect another two weeks or so of data if all goes 
> according to plan.
> 
> I'm really only interested in the longer term numbers and I 
> wouldn't put to much trust in the shorter term results.
> 
> Comments would be welcome especially if there is a 
> fundamental flaw with this process.   
> 
> Looking at the data gave me something to do this afternoon 
> during some down time on a business trip (:  I reazlize this 
> approach is probably not how the pros would do this.
> 
> Regards Mark Spencer
>  


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] UK: GPS Jamming Notices

[David J Taylor]

I have received the three following notices:


NOTIFICATION OF GPS JAMMING EXERCISES STANFORD TRAINING AREA, EAST ANGLIA, 
FEBRUARY 2013


Dates: Between 11 and 15 February 2013.
Times: 0900 -1600 GMT.
Location of MULTIPLE jammers: Land based within 5km of N52° 29.0’ E000° 45.0’.
Frequency: A 24 MHz band centred around 1575.42MHz (GPS L1).
Total Power: Up to 10 Watts EIRP.
It is stressed that, as in previous exercises, Safety of Life operations 
will at all times take precedence over exercise activities.






NOTIFICATION OF GPS JAMMING EXERCISES OFF THE COAST OF EAST ANGLIA, 
FEBRUARY/MARCH 2013


Dates: 25 to 26 February and 28 February to 1 March 2013.
Times: Intermittently for a 90 minute period in each time slot 0930-1200 GMT 
and 1400-1630 GMT.
Location of jammers: Sea based omni-directional jammer onboard a vessel 
sailing within the Experimental Buoys area, as charted, but no further North 
than 51°55’N in the area bound by following boundary positions (WGS84):

* 51.916667°N 1.453745°E  (51° 55.0’N  1°27.2’E)
* 51.883980°N 1.445504°E  (51° 53.0’N  1°26.7’E)
* 51.883607°N 1.397795°E  (51° 53.0’N  1°23.9’E)
* 51.916667°N 1.421994°E  (51° 55.0’N  1°25.3’E)
Frequency: 24 MHz bands centred around 1575.42MHz.
Total Power: 0.0005 Watts ERP maximum so as not to effect vessels outside 
the area bounded by the co-ordinates above or aircraft flying above 2500ft.
It is stressed that, as in previous exercises, Safety of Life operations 
will at all times take precedence over exercise activities.






NOTIFICATION OF GPS JAMMING EXERCISES RAF SCULTHORPE AIRFIELD, EAST ANGLIA, 
MARCH 2013


Dates:   25th and 29th March 2013.
Times: 0700 -1700 BST.
Location of SINGLE jammer: Land based within 2km of 52° 50′ 54″ N, 0° 45′ 
38″ E

Frequency: A 20 MHz band centred around 1575.42MHz (GPS L1).
Power: Up to 0.3 Watts EIRP (300mW).
Jammers: Omni-directional jammers radiating CW.
It is stressed that, Safety of Life operations will at all times take 
precedence over exercise activities.




David
--
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] UK: GPS Jamming Notices

[lists]

Relative to the last notice, a CW jammer would be at a single frequency, so it 
seems odd they specify a band. Perhaps a CW anywhere in that band.

I talked to the USAF about their jamming, and they use white noise over the 
band. A certain COTS Marconi (IIRC) signal generator produces the band limited 
noise and puts it on the carrier. 

-Original Message-
From: "David J Taylor" 
Sender: time-nuts-boun...@febo.com
Date: Mon, 3 Dec 2012 12:16:12 
To: Time-nuts mailing list
Reply-To: Discussion of precise time and frequency measurement

Subject: [time-nuts] UK: GPS Jamming Notices

I have received the three following notices:


NOTIFICATION OF GPS JAMMING EXERCISES STANFORD TRAINING AREA, EAST ANGLIA, 
FEBRUARY 2013

Dates: Between 11 and 15 February 2013.
Times: 0900 -1600 GMT.
Location of MULTIPLE jammers: Land based within 5km of N52° 29.0’ E000° 45.0’.
Frequency: A 24 MHz band centred around 1575.42MHz (GPS L1).
Total Power: Up to 10 Watts EIRP.
It is stressed that, as in previous exercises, Safety of Life operations 
will at all times take precedence over exercise activities.





NOTIFICATION OF GPS JAMMING EXERCISES OFF THE COAST OF EAST ANGLIA, 
FEBRUARY/MARCH 2013

Dates: 25 to 26 February and 28 February to 1 March 2013.
Times: Intermittently for a 90 minute period in each time slot 0930-1200 GMT 
and 1400-1630 GMT.
Location of jammers: Sea based omni-directional jammer onboard a vessel 
sailing within the Experimental Buoys area, as charted, but no further North 
than 51°55’N in the area bound by following boundary positions (WGS84):
* 51.916667°N 1.453745°E  (51° 55.0’N  1°27.2’E)
* 51.883980°N 1.445504°E  (51° 53.0’N  1°26.7’E)
* 51.883607°N 1.397795°E  (51° 53.0’N  1°23.9’E)
* 51.916667°N 1.421994°E  (51° 55.0’N  1°25.3’E)
Frequency: 24 MHz bands centred around 1575.42MHz.
Total Power: 0.0005 Watts ERP maximum so as not to effect vessels outside 
the area bounded by the co-ordinates above or aircraft flying above 2500ft.
It is stressed that, as in previous exercises, Safety of Life operations 
will at all times take precedence over exercise activities.





NOTIFICATION OF GPS JAMMING EXERCISES RAF SCULTHORPE AIRFIELD, EAST ANGLIA, 
MARCH 2013

Dates:   25th and 29th March 2013.
Times: 0700 -1700 BST.
Location of SINGLE jammer: Land based within 2km of 52° 50′ 54″ N, 0° 45′ 
38″ E
Frequency: A 20 MHz band centred around 1575.42MHz (GPS L1).
Power: Up to 0.3 Watts EIRP (300mW).
Jammers: Omni-directional jammers radiating CW.
It is stressed that, Safety of Life operations will at all times take 
precedence over exercise activities.



David
-- 
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-tay...@blueyonder.co.uk 


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Measuring GPS noise floor (sort of)

[Mark Spencer]

Thanks for the comments and suggestions.

With regards to the equipment used to collect the data, I am using two HP 
5370B's.   The 1 pps output of the PRS10 is connected to the start input of 
each counter, the 10Mhz output of each of the GPSDO's is connected to the stop 
input of one of the counters.  The 10 Mhz output from the PRS10 is also routed 
via a distribution amp to the reference input of both counters.   I'm confident 
that the measurements are below the noise floor of the counters beyond approx 
100 seconds.   The trigger settings on the start input of each counter are 
identical so I'm hopeful the measurements are being taken at more or less the 
same time.   

With regards to the common mode issues, yes this crossed my mind, and I expect 
what I will end up measuring will likely be a function of the longer term 
performance of the lesser of the two receivers rather than the true GPS noise 
floor. I should probably have made the "sort of" disclaimer in the title of the 
thread stronger (:  Still I expect this would give me an indication of the 
likely long term performance of the two GPS receivers in question which from my 
end user perspective is still useful.   

The two receivers do however receive different numbers of satellites so I'm 
thinking some GPS system bias may work it's way into the measurements over the 
long term.  I am curious if at some point I will see the computed Adev between 
the two GPSDO's flatten out and trend upwards.

The comment regarding the differences in the performance of the GPSDO's vs the 
GPS system itself also makes sense.

Regards
Mark Spencer
> Message: 5
> Date: Mon, 03 Dec 2012 00:17:47 +0100
> From: Magnus Danielson 
> To: time-nuts@febo.com
> Subject: Re: [time-nuts] Measuring GPS noise floor (sort
> of)
> Message-ID: <50bbe19b.3040...@rubidium.dyndns.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> On 12/02/2012 11:37 PM, Mark Spencer wrote:
> > I'm wondering how useful it is to compare two different
> GPS receivers to a single Rb to get a sense of the GPS noise
> floor.   I've been collecting some data for
> the last week or so seem be making some headway with this.
> >
> > Not having a cesium or an Hmaser I elected to compare
> two different GPSDO's to a single Rb and then assuming the
> data seemed sane, I thought I would then compute the Adev
> between the two GPSDO's.   My assumption is
> that by comparing the two GPSDO's to the Rb it should be
> possible to detect when one GPSDO is mis behaving or
> possibly when the Rb mis behaves.  So far other than a
> bit of a glitch at the start of the process things seem to
> be proceeding as I expected.   I hope to
> collect another two weeks or so of data if all goes
> according to plan.
> >
> > I'm really only interested in the longer term numbers
> and I wouldn't put to much trust in the shorter term
> results.
> >
> > Comments would be welcome especially if there is a
> fundamental flaw with this process.
> >
> > Looking at the data gave me something to do this
> afternoon during some down time on a business trip (: 
> I reazlize this approach is probably not how the pros would
> do this.
> 
> You do realize that several issues with the GPSDOs will be
> common mode, 
> such as the errors of the ionspheric model and actual
> ionspheric effect 
> and that of multipath. The rubidium will to some degree aid
> to 
> illustrate these shifts, but it will be accounted for on the
> rubidium 
> deviation from the common. If you look at the CRIT paper we
> discussed 
> yesterday, they did exactly what you proposes. For most
> stuff the 5 
> recievers they used didn't show much differences. If you
> increase the 
> resolution you might get out more. You might have use for
> additional 
> local references, in order to separate out other effects.
> For instance, 
> with three rubidiums measured, you could single out which of
> them has an 
> error, and any common mode effects of the GPSDOs could be
> fairly well 
> separated out from the local performance of your rubidiums.
> 
> Cheers,
> Magnus
> 
> 
> 



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Measuring GPS noise floor (sort of)

[Mark Spencer]

Sorry I meant to say I'm confident the measurements are above the noise floor 
after approx 100 seconds.  



--
On Mon, 3 Dec, 2012 4:56 AM PST Mark Spencer wrote:

>Thanks for the comments and suggestions.
>
>With regards to the equipment used to collect the data, I am using two HP 
>5370B's.   The 1 pps output of the PRS10 is connected to the start input of 
>each counter, the 10Mhz output of each of the GPSDO's is connected to the stop 
>input of one of the counters.  The 10 Mhz output from the PRS10 is also routed 
>via a distribution amp to the reference input of both counters.   I'm 
>confident that the measurements are below the noise floor of the counters 
>beyond approx 100 seconds.   The trigger settings on the start input of each 
>counter are identical so I'm hopeful the measurements are being taken at more 
>or less the same time.   
>
>With regards to the common mode issues, yes this crossed my mind, and I expect 
>what I will end up measuring will likely be a function of the longer term 
>performance of the lesser of the two receivers rather than the true GPS noise 
>floor. I should probably have made the "sort of" disclaimer in the title of 
>the thread stronger (:  Still I expect this would give me an indication of the 
>likely long term performance of the two GPS receivers in question which from 
>my end user perspective is still useful.   
>
>The two receivers do however receive different numbers of satellites so I'm 
>thinking some GPS system bias may work it's way into the measurements over the 
>long term.  I am curious if at some point I will see the computed Adev between 
>the two GPSDO's flatten out and trend upwards.
>
>The comment regarding the differences in the performance of the GPSDO's vs the 
>GPS system itself also makes sense.
>
>Regards
>Mark Spencer
>> Message: 5
>> Date: Mon, 03 Dec 2012 00:17:47 +0100
>> From: Magnus Danielson 
>> To: time-nuts@febo.com
>> Subject: Re: [time-nuts] Measuring GPS noise floor (sort
>> of)
>> Message-ID: <50bbe19b.3040...@rubidium.dyndns.org>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> 
>> On 12/02/2012 11:37 PM, Mark Spencer wrote:
>> > I'm wondering how useful it is to compare two different
>> GPS receivers to a single Rb to get a sense of the GPS noise
>> floor.   I've been collecting some data for
>> the last week or so seem be making some headway with this.
>> >
>> > Not having a cesium or an Hmaser I elected to compare
>> two different GPSDO's to a single Rb and then assuming the
>> data seemed sane, I thought I would then compute the Adev
>> between the two GPSDO's.   My assumption is
>> that by comparing the two GPSDO's to the Rb it should be
>> possible to detect when one GPSDO is mis behaving or
>> possibly when the Rb mis behaves.  So far other than a
>> bit of a glitch at the start of the process things seem to
>> be proceeding as I expected.   I hope to
>> collect another two weeks or so of data if all goes
>> according to plan.
>> >
>> > I'm really only interested in the longer term numbers
>> and I wouldn't put to much trust in the shorter term
>> results.
>> >
>> > Comments would be welcome especially if there is a
>> fundamental flaw with this process.
>> >
>> > Looking at the data gave me something to do this
>> afternoon during some down time on a business trip (: 
>> I reazlize this approach is probably not how the pros would
>> do this.
>> 
>> You do realize that several issues with the GPSDOs will be
>> common mode, 
>> such as the errors of the ionspheric model and actual
>> ionspheric effect 
>> and that of multipath. The rubidium will to some degree aid
>> to 
>> illustrate these shifts, but it will be accounted for on the
>> rubidium 
>> deviation from the common. If you look at the CRIT paper we
>> discussed 
>> yesterday, they did exactly what you proposes. For most
>> stuff the 5 
>> recievers they used didn't show much differences. If you
>> increase the 
>> resolution you might get out more. You might have use for
>> additional 
>> local references, in order to separate out other effects.
>> For instance, 
>> with three rubidiums measured, you could single out which of
>> them has an 
>> error, and any common mode effects of the GPSDOs could be
>> fairly well 
>> separated out from the local performance of your rubidiums.
>> 
>> Cheers,
>> Magnus
>> 
>> 
>> 
>
>


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Using a frequency synthesizer replacement for motherboard oscillator

[Erich Heine]

On Sun, Dec 2, 2012 at 3:16 PM, Magnus Danielson  wrote:

> Erich,
>
>
> On 12/02/2012 08:54 PM, Erich Heine wrote:
>
>> Jonathan,
>>
>> My research group has had some good experiences using products from
>> Endace (
>> http://www.endace.com/) for network timing measurement at the ethernet
>> level. I don't have a pointer immediately to the work, but if there is
>> interest can ask tomorrow at work. The gist of it though was to understand
>> precise timing characteristics of network switches for better simulation.
>> Examining the time "in switch" for various packets at the microsecond
>> level
>> was needed to understand various delay curves for different network loads,
>> with an ultimate goal of proper statistical modeling reflecting reality as
>> close as possible.
>>
>
> This is a bold challenge, it's a difficult task (clear speak: there is a
> reason for this to be a research field, industry never *really* got it
> under control).
>
>
It is a challenge. I'll have to re evaluate my understanding of the timing
characteristics of the card in light of my new and growing knowledge on
timing. However, this is what I understand now:

I'm sure the timing isn't perfect, but we mitigated some of the potential
clock issues by doing many runs of tests. Further a single endace DAG card
has 2 or 4 network ports on it, so timing can be measured across a network
to the same card with the same reference clock which helps simplify error
source.  (The card has a feature which allows time stamping packets on the
card from that reference clock). Also there is a mechanism by which the
endace cards can be connected directly to each other to synchronize their
clocks to each other, so packet timings across cards can well measured.

I wasn't very involved in the details of the project I'm describing, so I
can't speak to how well any one of those functionalities of the cards
performed, nor how much error we saw or tolerated, I'll ask those folks
later today (as I happen to have a meeting with them about other stuff
anyway :))

One thing I can speak to though, is that in simulation of the type they are
doing - the general granularity of the simulation results are on the order
of 10^-3, so understanding the switches at 10^-6 isn't used directly in the
simulation, but rather to build probability distribution functions that
capture the behavior of the switches well enough to see cumulative results
comparable to observed networking conditions (e.g. the result of N switches
handling serializing events under certain loads will get packet trains like
$X and other loads like $Y and so on). One thing the PI on that project
mentioned was the shape of those functions being correct is the highest
priority. I understand this to mean that the errors "average out" (not an
actual mean, but through some statistics I don't understand all the way yet
they stop being significant compared to other issues).

Perhaps I'll need to point those researchers at this list to find out ways
to better get the timings they want :)


>  I personally have also used endace products to measure packet timings for
>> research, but I didn't need so much precision for that work - however I
>> can
>> say they have a good API and decent tech support for interacting with
>> their
>> cards and products.
>>
>
> Is there native support with Linux kernels?
> It would be very nice to have the support using SO_TIMESTAMP and friends.
>
>
It's been a couple of years since I got deep on this, so I don't remember
details. I do know all the work we've done with the cards was on Linux, and
it worked nicely - I had no issues that were OS related. One thing about
the paradigm for the DAG cards is they are not in the standard networking
stack. They expose themselves from the kernel in a different way via an API
(which Endace provides the source for). To do IP networking with them, you
need to provided your own network stack in userland - however this is out
of the scope of the companies goal. They are really about providing high
speed layer2 access. I believe their primary use cases are research like we
did, and extremely low-latency communications between machines in clusters
(targeting high frequency traders and the like).


> Cheers,
> Magnus
>
>
> __**_
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/**
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Time security musing - attacking the clock itself

[Erich Heine]

One of my favorite things about being in security, (and a researcher in
general), is that we regularly get to say "that sounds too hard, what if we
look $HERE instead". So while I catch up on security in the time
synchronization space, I've also been musing on this notion of attacking
the clock. By this I mean I am going to assume the protocols for
synchronization are secure and instead look at other things which can
affect measurement timestamping.

I also am going to assume that an attacker doesn't just want to bring down
any system dependent on compromised devices, but rather wants to cause
instabilities, inefficiencies and other long-term damage (for whatever
reasons - economic, political, revenge, whatever - a good attack is
frequently one that doesn't bring down a system, but instead makes it
untrustworthy and is hard to eradicate).

In my space (power grid) there is a lot of work being done to get good
synchronized measurement of the whole wide-area system. This of course
depends on trusting the clock. Many calculations of state, and problem
detection (e.g. various forms of oscillation) implicitly trust the
measurement is accurate within defined error bands, including time.

What I've learned from reading this list is that clocks are pretty
sensitive - a lot of factors can affect the reliability (and hence
trustworthiness) of the reported time.

So what I am trying to understand today is ways we can affect the
reliability of the clock, having affects on everything mentioned above.

Some scenarios:

1) I am an attacker. I can get remote root access to a device that depends
on an internal clock synchronized to a trusted source. I don't want to
leave changes in the main firmware/os that are detectable. Once the device
is rebooted I want no obvious signs I was ever there. A common technique
for this is to put exploits into secondary controller chips in the device.
(System boards these days look more like networks of computers than a
single computer - all sorts of chips providing functionality are just
microcontrollers themselves with writable firmware, but limited
introspection capability, making them a prime target for attack). Like I
said, I want to attack the clock and make it unreliable.

* Is there a specific chip/subsystem that can be be modified via firmware
to mess up the clock? I presume there is because the synchronization comes
in off the network. What sort of modifications to the code of that firmware
would break it?

* Is the method for reading the clock a directly wired GPIO pin, or is it
on a shared bus like I2C or SPI? (If so, other things on the bus could be
compromised instead to not play nice with bus and affect readings)

* Is the system clock used to drive things like ADCs, if so can messing
with the clock affect calibration of the readings?

2) I don't have access to devices or network. Is there a way to mess with
the time signal that is very difficult to detect. Say GPS spoofing is  no
longer a "safe" option. It seems there are a lot of sensitivities in the
timing chain. What sort of factors affect a clock signal?

* Random thought - Can I point a highly directed microwave beam at the coax
from the GPS antenna to the clock to cause noise inside that channel?

* What else can be used to cause external interference to timing, even in
well designed clocks?

3) I have a long planning horizon, and access to the devices at some point
in the supply chain. What sort of small tweaks can I make to the circuit
that are easy and indistinguishable from poor quality control that would
add a lot of noise to a timing signal? Are these things all on a single
chip? Are there traces/components that can be altered/damaged/affected with
strange inductive effects?


So Time-Nuts - what are your thoughts on this musing? I am hoping you all
can provide some insight as to wether these are productive questions to
pursue, or feedback and experience on these type of problems. Mostly
though, I'm working towards a general refinement of my understanding, and I
do that best through feedback :).

Regards,
Erich
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Bob Camp]

Hi

One very basic question might be - is a public list read by millions of
people the right place to dig into this?

The most basic thing you can detect is "time went backwards". Obviously, it
should never to this. Because it's easy to detect, I'd assume that the
attacker isn't going to do anything gross. Instead they would try to steer
the clock so it slowly goes out of step with the real world.

If that's correct, then the answer to most of the rest of the questions is
no. A small frequency offset is adequate to do the steer. That sort of
offset isn't going to mess up things like ADC's and com ports. A microsecond
per second slip is a 1 ppm frequency offset. There's nothing in a off the
shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other than
the real time clock..). 

One hundred microseconds per second is plenty of slip to get things into an
odd state. By the end of 24 hours, you would be off by 8.64 seconds. 

Bob  

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Erich Heine
Sent: Monday, December 03, 2012 11:30 AM
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] Time security musing - attacking the clock itself

One of my favorite things about being in security, (and a researcher in
general), is that we regularly get to say "that sounds too hard, what if we
look $HERE instead". So while I catch up on security in the time
synchronization space, I've also been musing on this notion of attacking
the clock. By this I mean I am going to assume the protocols for
synchronization are secure and instead look at other things which can
affect measurement timestamping.

I also am going to assume that an attacker doesn't just want to bring down
any system dependent on compromised devices, but rather wants to cause
instabilities, inefficiencies and other long-term damage (for whatever
reasons - economic, political, revenge, whatever - a good attack is
frequently one that doesn't bring down a system, but instead makes it
untrustworthy and is hard to eradicate).

In my space (power grid) there is a lot of work being done to get good
synchronized measurement of the whole wide-area system. This of course
depends on trusting the clock. Many calculations of state, and problem
detection (e.g. various forms of oscillation) implicitly trust the
measurement is accurate within defined error bands, including time.

What I've learned from reading this list is that clocks are pretty
sensitive - a lot of factors can affect the reliability (and hence
trustworthiness) of the reported time.

So what I am trying to understand today is ways we can affect the
reliability of the clock, having affects on everything mentioned above.

Some scenarios:

1) I am an attacker. I can get remote root access to a device that depends
on an internal clock synchronized to a trusted source. I don't want to
leave changes in the main firmware/os that are detectable. Once the device
is rebooted I want no obvious signs I was ever there. A common technique
for this is to put exploits into secondary controller chips in the device.
(System boards these days look more like networks of computers than a
single computer - all sorts of chips providing functionality are just
microcontrollers themselves with writable firmware, but limited
introspection capability, making them a prime target for attack). Like I
said, I want to attack the clock and make it unreliable.

* Is there a specific chip/subsystem that can be be modified via firmware
to mess up the clock? I presume there is because the synchronization comes
in off the network. What sort of modifications to the code of that firmware
would break it?

* Is the method for reading the clock a directly wired GPIO pin, or is it
on a shared bus like I2C or SPI? (If so, other things on the bus could be
compromised instead to not play nice with bus and affect readings)

* Is the system clock used to drive things like ADCs, if so can messing
with the clock affect calibration of the readings?

2) I don't have access to devices or network. Is there a way to mess with
the time signal that is very difficult to detect. Say GPS spoofing is  no
longer a "safe" option. It seems there are a lot of sensitivities in the
timing chain. What sort of factors affect a clock signal?

* Random thought - Can I point a highly directed microwave beam at the coax
from the GPS antenna to the clock to cause noise inside that channel?

* What else can be used to cause external interference to timing, even in
well designed clocks?

3) I have a long planning horizon, and access to the devices at some point
in the supply chain. What sort of small tweaks can I make to the circuit
that are easy and indistinguishable from poor quality control that would
add a lot of noise to a timing signal? Are these things all on a single
chip? Are there traces/components that can be altered/damaged/affected with
strange inductive effects?


So Time-Nuts - 

Re: [time-nuts] 3120A Phase Noise Test Probe

[shalimr9]

Well, I hope they made it worth your while!

Congrats!

Didier

Sent from my Droid Razr 4G LTE wireless tracker.



-Original Message-
From: John Miles 
To: 'Discussion of precise time and frequency measurement' 
Sent: Sun, 02 Dec 2012 11:33 PM
Subject: Re: [time-nuts] 3120A Phase Noise Test Probe

Thanks, guys!  Sorry about the price increase, that wasn't my doing. :)

-- john, KE5FX

> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-
> boun...@febo.com] On Behalf Of Tom Knox
> Sent: Saturday, December 01, 2012 4:33 PM
> To: Time-Nuts
> Subject: Re: [time-nuts] 3120A Phase Noise Test Probe
> 
> 
> Great to hear John.
> 
> Thomas Knox
> 
> 
> 
> > Date: Sat, 1 Dec 2012 13:24:35 -0700
> > From: ke...@rosenberg.net
> > To: time-nuts@febo.com
> > Subject: Re: [time-nuts] 3120A Phase Noise Test Probe
> >
> > Magnus Danielson wrote:
> > > Congratulation John! Good work!
> >
> > Truly well-deserved, John!
> >
> > Kevin
> >


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[dlewis6767]

I agree, Bob.

Like the billboard on the side of the highway says: - Does Advertising Work? 
JUST DID -


The bad guys can read this list same as the good guys.









--
From: "Bob Camp" 
Sent: Monday, December 03, 2012 11:18 AM
To: "'Discussion of precise time and frequency measurement'" 


Subject: Re: [time-nuts] Time security musing - attacking the clock itself


Hi

One very basic question might be - is a public list read by millions of
people the right place to dig into this?

The most basic thing you can detect is "time went backwards". Obviously, 
it

should never to this. Because it's easy to detect, I'd assume that the
attacker isn't going to do anything gross. Instead they would try to steer
the clock so it slowly goes out of step with the real world.

If that's correct, then the answer to most of the rest of the questions is
no. A small frequency offset is adequate to do the steer. That sort of
offset isn't going to mess up things like ADC's and com ports. A 
microsecond

per second slip is a 1 ppm frequency offset. There's nothing in a off the
shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other than
the real time clock..).

One hundred microseconds per second is plenty of slip to get things into 
an

odd state. By the end of 24 hours, you would be off by 8.64 seconds.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Erich Heine
Sent: Monday, December 03, 2012 11:30 AM
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] Time security musing - attacking the clock itself

One of my favorite things about being in security, (and a researcher in
general), is that we regularly get to say "that sounds too hard, what if 
we

look $HERE instead". So while I catch up on security in the time
synchronization space, I've also been musing on this notion of attacking
the clock. By this I mean I am going to assume the protocols for
synchronization are secure and instead look at other things which can
affect measurement timestamping.

I also am going to assume that an attacker doesn't just want to bring down
any system dependent on compromised devices, but rather wants to cause
instabilities, inefficiencies and other long-term damage (for whatever
reasons - economic, political, revenge, whatever - a good attack is
frequently one that doesn't bring down a system, but instead makes it
untrustworthy and is hard to eradicate).

In my space (power grid) there is a lot of work being done to get good
synchronized measurement of the whole wide-area system. This of course
depends on trusting the clock. Many calculations of state, and problem
detection (e.g. various forms of oscillation) implicitly trust the
measurement is accurate within defined error bands, including time.

What I've learned from reading this list is that clocks are pretty
sensitive - a lot of factors can affect the reliability (and hence
trustworthiness) of the reported time.

So what I am trying to understand today is ways we can affect the
reliability of the clock, having affects on everything mentioned above.

Some scenarios:

1) I am an attacker. I can get remote root access to a device that depends
on an internal clock synchronized to a trusted source. I don't want to
leave changes in the main firmware/os that are detectable. Once the device
is rebooted I want no obvious signs I was ever there. A common technique
for this is to put exploits into secondary controller chips in the device.
(System boards these days look more like networks of computers than a
single computer - all sorts of chips providing functionality are just
microcontrollers themselves with writable firmware, but limited
introspection capability, making them a prime target for attack). Like I
said, I want to attack the clock and make it unreliable.

* Is there a specific chip/subsystem that can be be modified via firmware
to mess up the clock? I presume there is because the synchronization comes
in off the network. What sort of modifications to the code of that 
firmware

would break it?

* Is the method for reading the clock a directly wired GPIO pin, or is it
on a shared bus like I2C or SPI? (If so, other things on the bus could be
compromised instead to not play nice with bus and affect readings)

* Is the system clock used to drive things like ADCs, if so can messing
with the clock affect calibration of the readings?

2) I don't have access to devices or network. Is there a way to mess with
the time signal that is very difficult to detect. Say GPS spoofing is  no
longer a "safe" option. It seems there are a lot of sensitivities in the
timing chain. What sort of factors affect a clock signal?

* Random thought - Can I point a highly directed microwave beam at the 
coax

from the GPS antenna to the clock to cause noise inside that channel?

* What else can be used to cause external interference to timing, even in
well d

Re: [time-nuts] Time security musing - attacking the clock itself

[Scott McGrath]

And proprietary security schemes always fail due to insufficient vetting.  
Security by obscurity is not security at all IPsec is secure because it it's 
inner workings are there for all to see and it's never been broken the 
compromises have happened because of poor key management not because of 
weaknesses in the underlying protocol.   AES is secure for the same reason and 
NTP and derivatives can be secured with MD5 and that's built into the protocol. 
  

BGP the protocol that runs Internet for a long time was insecure because the 
updates were not secured this was fixed a few years back when the big guys said 
you can't peer with us unless you use secure updates.   DNS is going through 
the same issue. DNSSEC secures DNS records but in order to work needs various 
levels of key distribution all the way down to the client if you want a really 
secure system

The issue is administrative not technical.  Clocks can be secured but currently 
are not because its a pain to manage keys securely

The military uses most of the same crypto systems that the commercial world 
uses but what they do better is key management.  How many commercial devices 
have a 'zeroize key' button on them.  All military devices do so if there is a 
risk that the key is about to be compromised it can be zapped securely and 
permanently and with a commercial crypto system there is nothing to be learned 
from device itself once key is gone


Scott

Sent from my iPhone

On Dec 3, 2012, at 12:32 PM, "dlewis6767"  wrote:

> I agree, Bob.
> 
> Like the billboard on the side of the highway says: - Does Advertising Work? 
> JUST DID -
> 
> The bad guys can read this list same as the good guys.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> From: "Bob Camp" 
> Sent: Monday, December 03, 2012 11:18 AM
> To: "'Discussion of precise time and frequency measurement'" 
> 
> Subject: Re: [time-nuts] Time security musing - attacking the clock itself
> 
>> Hi
>> 
>> One very basic question might be - is a public list read by millions of
>> people the right place to dig into this?
>> 
>> The most basic thing you can detect is "time went backwards". Obviously, it
>> should never to this. Because it's easy to detect, I'd assume that the
>> attacker isn't going to do anything gross. Instead they would try to steer
>> the clock so it slowly goes out of step with the real world.
>> 
>> If that's correct, then the answer to most of the rest of the questions is
>> no. A small frequency offset is adequate to do the steer. That sort of
>> offset isn't going to mess up things like ADC's and com ports. A microsecond
>> per second slip is a 1 ppm frequency offset. There's nothing in a off the
>> shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other than
>> the real time clock..).
>> 
>> One hundred microseconds per second is plenty of slip to get things into an
>> odd state. By the end of 24 hours, you would be off by 8.64 seconds.
>> 
>> Bob
>> 
>> -Original Message-
>> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
>> Behalf Of Erich Heine
>> Sent: Monday, December 03, 2012 11:30 AM
>> To: Discussion of precise time and frequency measurement
>> Subject: [time-nuts] Time security musing - attacking the clock itself
>> 
>> One of my favorite things about being in security, (and a researcher in
>> general), is that we regularly get to say "that sounds too hard, what if we
>> look $HERE instead". So while I catch up on security in the time
>> synchronization space, I've also been musing on this notion of attacking
>> the clock. By this I mean I am going to assume the protocols for
>> synchronization are secure and instead look at other things which can
>> affect measurement timestamping.
>> 
>> I also am going to assume that an attacker doesn't just want to bring down
>> any system dependent on compromised devices, but rather wants to cause
>> instabilities, inefficiencies and other long-term damage (for whatever
>> reasons - economic, political, revenge, whatever - a good attack is
>> frequently one that doesn't bring down a system, but instead makes it
>> untrustworthy and is hard to eradicate).
>> 
>> In my space (power grid) there is a lot of work being done to get good
>> synchronized measurement of the whole wide-area system. This of course
>> depends on trusting the clock. Many calculations of state, and problem
>> detection (e.g. various forms of oscillation) implicitly trust the
>> measurement is accurate within defined error bands, including time.
>> 
>> What I've learned from reading this list is that clocks are pretty
>> sensitive - a lot of factors can affect the reliability (and hence
>> trustworthiness) of the reported time.
>> 
>> So what I am trying to understand today is ways we can affect the
>> reliability of the clock, having affects on everything mentioned above.
>> 
>> Some scenarios:
>> 
>> 1) I am an attacker. I can get remote root access to a device that de

Re: [time-nuts] Time security musing - attacking the clock itself

[Edgardo Molina]

Dear Erich,

I will allow myself to comment briefly on the RF part of your concerns.

>> * Random thought - Can I point a highly directed microwave beam at the coax
>> from the GPS antenna to the clock to cause noise inside that channel?


GPS signals are very low level as we all know and are subject to jamming either 
intentional or accidental as you are wondering with your microwave signal 
towards the transmission line. I bet that the majority of the interfering 
signal will be picked up by the GPS antenna and not by the transmission line. 
But if the transmission line has nicks, loose couplings or poor shield quality, 
it will definitely allow the interfering signal to come into the receiver. As a 
matter of fact, let me ask you this. How concentrated a microwave signal can 
practically be to cause the damage pointing it to a specific element of the RF 
chain from a distance? 1º,3º or 10º  in the H-V radiation patterns? What kind 
of antenna design would be practical for this radiation pattern generation? A 
deep parabolic dish? Corner reflector? A twenty-something elemet Yagi? At a 
distance, the signal dispersion will certainly not only hit the transmission 
line but the GPS antenna and possibly the receiver as well. Remember the 
microwave signal reflects from nearby objects as well and can cause a change in 
the wave propagation path. 

There are numerous papers and articles on GPS jamming and interference. Again, 
take a look at NIST archive. You will be delighted when reading about 
unintentional interference to GPS because of loose connectors in the RF chain.

Thank you.


Regards,



Edgardo Molina
Dirección IPTEL

www.iptel.net.mx

T : 55 55 55202444
M : 04455 10045822

Piensa en Bits SA de CV



Información anexa:




CONFIDENCIALIDAD DE INFORMACION

Este mensaje tiene carácter confidencial. Si usted no es el destinarario de 
este mensaje, le suplicamos se lo notifique al remitente mediante un correo 
electrónico y que borre el presente mensaje y sus anexos de su computadora sin 
retener una copia de los mismos. Queda estrictamente prohibido copiar este 
mensaje o hacer usode el para cualquier propósito o divulgar su en forma 
parcial o total su contenido. Gracias.


NON-DISCLOSURE OF INFORMATION

This email is strictly confidential and may also be privileged. If you are not 
the intended recipient please immediately advise the sender by replying to this 
e-mail and then deleting the message and its attachments from your computer 
without keeping a copy. It is strictly forbidden to copy it or use it for any 
purpose or disclose its contents to any third party. Thank you.






On Dec 3, 2012, at 11:32 AM, "dlewis6767"  wrote:

> I agree, Bob.
> 
> Like the billboard on the side of the highway says: - Does Advertising Work? 
> JUST DID -
> 
> The bad guys can read this list same as the good guys.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> From: "Bob Camp" 
> Sent: Monday, December 03, 2012 11:18 AM
> To: "'Discussion of precise time and frequency measurement'" 
> 
> Subject: Re: [time-nuts] Time security musing - attacking the clock itself
> 
>> Hi
>> 
>> One very basic question might be - is a public list read by millions of
>> people the right place to dig into this?
>> 
>> The most basic thing you can detect is "time went backwards". Obviously, it
>> should never to this. Because it's easy to detect, I'd assume that the
>> attacker isn't going to do anything gross. Instead they would try to steer
>> the clock so it slowly goes out of step with the real world.
>> 
>> If that's correct, then the answer to most of the rest of the questions is
>> no. A small frequency offset is adequate to do the steer. That sort of
>> offset isn't going to mess up things like ADC's and com ports. A microsecond
>> per second slip is a 1 ppm frequency offset. There's nothing in a off the
>> shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other than
>> the real time clock..).
>> 
>> One hundred microseconds per second is plenty of slip to get things into an
>> odd state. By the end of 24 hours, you would be off by 8.64 seconds.
>> 
>> Bob
>> 
>> -Original Message-
>> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
>> Behalf Of Erich Heine
>> Sent: Monday, December 03, 2012 11:30 AM
>> To: Discussion of precise time and frequency measurement
>> Subject: [time-nuts] Time security musing - attacking the clock itself
>> 
>> One of my favorite things about being in security, (and a researcher in
>> general), is that we regularly get to say "that sounds too hard, what if we
>> look $HERE instead". So while I catch up on security in the time
>> synchronization space, I've also been musing on this notion of attacking
>> the clock. By this I mean I am going to assume the protocols for
>> synchronization are secure and instead look at other things which can
>> affect measurement timestamping.
>> 
>> I also am going to assume that an atta

Re: [time-nuts] Time security musing - attacking the clock itself

[Bob Camp]

Hi

If your GPS is sitting somewhere on the main power grid, it's often already
in a pretty massive electromagnet field. Early on they tried lower frequency
time sources and simply could not hear them above the noise of the power
plant or switching station. There are multiple papers from the 1970's and
80's going into this.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Edgardo Molina
Sent: Monday, December 03, 2012 1:11 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Time security musing - attacking the clock itself

Dear Erich,

I will allow myself to comment briefly on the RF part of your concerns.

>> * Random thought - Can I point a highly directed microwave beam at the
coax
>> from the GPS antenna to the clock to cause noise inside that channel?


GPS signals are very low level as we all know and are subject to jamming
either intentional or accidental as you are wondering with your microwave
signal towards the transmission line. I bet that the majority of the
interfering signal will be picked up by the GPS antenna and not by the
transmission line. But if the transmission line has nicks, loose couplings
or poor shield quality, it will definitely allow the interfering signal to
come into the receiver. As a matter of fact, let me ask you this. How
concentrated a microwave signal can practically be to cause the damage
pointing it to a specific element of the RF chain from a distance? 1º,3º or
10º  in the H-V radiation patterns? What kind of antenna design would be
practical for this radiation pattern generation? A deep parabolic dish?
Corner reflector? A twenty-something elemet Yagi? At a distance, the signal
dispersion will certainly not only hit the transmission line but the GPS
antenna and possibly the receiver as well. Remember the microwave signal
reflects from nearby objects as well and can cause a change in the wave
propagation path. 

There are numerous papers and articles on GPS jamming and interference.
Again, take a look at NIST archive. You will be delighted when reading about
unintentional interference to GPS because of loose connectors in the RF
chain.

Thank you.


Regards,



Edgardo Molina
Dirección IPTEL

www.iptel.net.mx

T : 55 55 55202444
M : 04455 10045822

Piensa en Bits SA de CV



Información anexa:




CONFIDENCIALIDAD DE INFORMACION

Este mensaje tiene carácter confidencial. Si usted no es el destinarario de
este mensaje, le suplicamos se lo notifique al remitente mediante un correo
electrónico y que borre el presente mensaje y sus anexos de su computadora
sin retener una copia de los mismos. Queda estrictamente prohibido copiar
este mensaje o hacer usode el para cualquier propósito o divulgar su en
forma parcial o total su contenido. Gracias.


NON-DISCLOSURE OF INFORMATION

This email is strictly confidential and may also be privileged. If you are
not the intended recipient please immediately advise the sender by replying
to this e-mail and then deleting the message and its attachments from your
computer without keeping a copy. It is strictly forbidden to copy it or use
it for any purpose or disclose its contents to any third party. Thank you.






On Dec 3, 2012, at 11:32 AM, "dlewis6767"  wrote:

> I agree, Bob.
> 
> Like the billboard on the side of the highway says: - Does Advertising
Work? JUST DID -
> 
> The bad guys can read this list same as the good guys.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> --
> From: "Bob Camp" 
> Sent: Monday, December 03, 2012 11:18 AM
> To: "'Discussion of precise time and frequency measurement'"

> Subject: Re: [time-nuts] Time security musing - attacking the clock itself
> 
>> Hi
>> 
>> One very basic question might be - is a public list read by millions of
>> people the right place to dig into this?
>> 
>> The most basic thing you can detect is "time went backwards". Obviously,
it
>> should never to this. Because it's easy to detect, I'd assume that the
>> attacker isn't going to do anything gross. Instead they would try to
steer
>> the clock so it slowly goes out of step with the real world.
>> 
>> If that's correct, then the answer to most of the rest of the questions
is
>> no. A small frequency offset is adequate to do the steer. That sort of
>> offset isn't going to mess up things like ADC's and com ports. A
microsecond
>> per second slip is a 1 ppm frequency offset. There's nothing in a off the
>> shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other
than
>> the real time clock..).
>> 
>> One hundred microseconds per second is plenty of slip to get things into
an
>> odd state. By the end of 24 hours, you would be off by 8.64 seconds.
>> 
>> Bob
>> 
>> -Original Message-
>> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
>> Behalf Of Erich Heine
>> Sent: Monday, December 03, 2012 11:30 AM
>> To: Discussion of precise time and frequency measurement

Re: [time-nuts] Using a frequency synthesizer replacement for motherboard oscillator

[Eric Garner]

I'm an applications engineer for a company that makes Ethernet controllers
and PHYs. Some of our customers use crystals (more often oscillators) that
they selected based on price rather than performance. when i'm debugging a
customer issue replacing the clock source with a synthesizer is a good
troubleshooting aid. I's also useful when trying to prove that a low
quality clock source (or clock distribution network) in a link partner is
producing a poor (usually jittery) output that makes it hard for our parts
to achieve link.



On Fri, Nov 30, 2012 at 5:06 PM, Jim Welch  wrote:

> OK, I'll bite.  Why?
>
> Jim
>
> >>>I've never done it using to the RTC crystal, but I  do it quite
> frequently in my Day Job to >>>Ethernet controllers on those same pc mother
> boards.
> >>>
> >>>-Eric
>
> On Fri, Nov 30, 2012 at 4:10 PM, Sarah White  wrote:
>
> > On 11/30/2012 6:30 PM, Eric Garner wrote:
> > > the actual RTC on modern (Intel based) PC's is driven from a
> > > standard
> > > 32,768 Hz crystal attached to the PCH. some of them are in
> > > incredibly
> > small
> > > packages now instead of the old tuning fork-in-a-can ones. peeling
> > > off
> > the
> > > load caps and crystal from the board would allow you plenty of
> > > spaces to tack down a lead from an external synthesizer.
> >
> > Yeah, the one on the (Soekis) example was pretty small. So far none of
> > of the replies have indicated that anyone on here has experience
> > beyond an embedded system.
> >
> > Mostly I started this thread because there have been a few with people
> > discussing implementing NTP on embedded microcontrollers, arduino, etc.
> > and I was thinking of doing it from the other side (turning a nice-ish
> > server into a rock-solid timekeeper)
> >
> > Thanks so far everyone. Really impressed that I already managed to get
> > 4x replies so quickly :)
> >
> >
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
> >
>
>
>
> --
> --Eric
> _
> Eric Garner
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>



-- 
--Eric
_
Eric Garner
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] PTTI 2012, part 2

[Tom Van Baak]

Continuing from previous posting...

> Still, there are always a number of talks of more general interest to us time 
> nuts.
> In the next few postings I'll give more details on a couple of topics:

- Neutrino time-of-flight update

Last years' faster-than-light neutrino fiasco is now old news, but I think many 
of us were curious how other neutrino experiments around the world would react. 
Not surprisingly, they all got very serious about precision timing! As one 
presenter mentioned, purchase orders for high-end timing gear were suddenly 
approved with remarkable ease.

There were a total of 6 talks by people working with neutrino experiments. From 
what I could tell (having done similar work at home) they totally have their 
act together now. NIST and USNO were involved with MINOS, the local US effort 
(neutrinos from FermiLab to the Soudan mine in Minnesota), both in providing 
gear (high-end dual-frequency or post-processed GPS receivers and local cesium 
clocks) to absolute calibration using TWSTFT (two way satellite time & 
frequency transfer).

One talk covered the challenge of measuring distance (presumably there are 
survey-nuts as well as time-nuts). You think measuring nanoseconds is hard 
until you hear what it takes to measure distance, including down an opaque 
slanted mineshaft, and get a final number like 734,286.554 meters!

While PTTI normally concerns itself with national timing laboratories, it was 
nice to see a whole new community (neutrino physics) get involved in the 
practical world of nanosecond timing.

- UTCr/Rapid UTC

Some of you know that TAI/UTC is computed from a monthly average of hundreds of 
atomic clocks around the world. Given the recent improvement in clock 
performance, intercontinental comparison techniques, and automated 
communications (internet), BIPM started a pilot program this year to generate a 
more responsive and fully automated "UTC". One problem with UTC is that 
physical measurements of, and virtual corrections to, contributing clocks 
occurs only once a month. This means that your national lab might drift a few 
ns before being told it is drifting.

Those of you who have built your own GPSDO or explored time constants can 
relate. So UTCr is an experiment where labs report *daily* and results are 
computed *weekly* based on a *monthly* moving average, or something like that. 
I had not heard about this before, but if you google for words like "Rapid UTC" 
UTCr BIPM you can learn more. The whole subject of time scales is deep and 
interesting.

- USNO rubidium fountains

While many national labs have developed cesium fountains (for accuracy), USNO 
has been gradually building rubidium fountain clocks (for stability) and 4 of 
them are now fully operational. The ADEV of these clocks gets well under 1e-16. 
The paper will have all the details but the note I made was that with 20 months 
of data, the stability was near 5e-17 at tau 4 months. That's 100x better than 
a commercial cesium standard; better than all of USNO's other 70 cesium clocks 
and 15 H-masers combined. Yes, I've added "rubidium fountain" to my automated 
eBay searches.

Like always, each of the Rb clocks is a little different. You measure this not 
by using an external reference (since no better clock is available) but by 
using the 3-cornered hat technique where you compare clock i against the mean 
of N clocks.

- WWVB/Xtendwave

This presentation was similar to the one made last year. From the talk, and 
discussions afterwards, it's clear good progress is being made. As of October 
29, 2012 the extended WWVB format is now default, but reception tests are 
continuing, and the format perhaps slightly tweaked. A prototype receiver was 
shown in a shoebox. I did not get to see inside.

My guess is that by next year we'll see real hardware and a final spec. I 
suggested the time-nuts community might be willing to test the new receivers 
when they are available. Contact me off-list if you want to help. I can't 
promise anything, but I know that NIST/Xtendwave have embarked on a project 
that will greatly improve reception quality and totally solve the DST 
announcement problems. I also believe that a passion-driven, no-cost, 
geographically-diverse set of time nuts can help make this a well-tuned success.

They also mentioned another cool feature being developed -- a high-rate 
modulation where, reception permitting, the entire 60 bit message is encoded 
into a single 1-second frame.

- Loran/UrsaNav

Not sure what to say about this presentation. Apparently this company got the 
rights to the US Loran transmitters(?) and plans to use them to provide an 
alternative source of precise time, for example, to the telecom community. CW 
instead of very low duty cycle Loran pulses would improve S/N and timing 
accuracy. You can probably read more about it on their web site. Any additional 
source of precise time is probably a good thing -- when NTP, WWVB, GPS, and 
your local atomic clock fails. 

Re: [time-nuts] Time security musing - attacking the clock itself

[Don Latham]

Well, if it's the current set of ruffians we're worried about, my guess
is a reasonably well-placed RPG would get the job done <1/2 :-)>.
Don L

Bob Camp
> Hi
>
> If your GPS is sitting somewhere on the main power grid, it's often
> already
> in a pretty massive electromagnet field. Early on they tried lower
> frequency
> time sources and simply could not hear them above the noise of the power
> plant or switching station. There are multiple papers from the 1970's
> and
> 80's going into this.
>
> Bob
>
> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
> Behalf Of Edgardo Molina
> Sent: Monday, December 03, 2012 1:11 PM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Time security musing - attacking the clock
> itself
>
> Dear Erich,
>
> I will allow myself to comment briefly on the RF part of your concerns.
>
>>> * Random thought - Can I point a highly directed microwave beam at
>>> the
> coax
>>> from the GPS antenna to the clock to cause noise inside that channel?
>
>
> GPS signals are very low level as we all know and are subject to jamming
> either intentional or accidental as you are wondering with your
> microwave
> signal towards the transmission line. I bet that the majority of the
> interfering signal will be picked up by the GPS antenna and not by the
> transmission line. But if the transmission line has nicks, loose
> couplings
> or poor shield quality, it will definitely allow the interfering signal
> to
> come into the receiver. As a matter of fact, let me ask you this. How
> concentrated a microwave signal can practically be to cause the damage
> pointing it to a specific element of the RF chain from a distance? 1º,3º
> or
> 10º  in the H-V radiation patterns? What kind of antenna design would be
> practical for this radiation pattern generation? A deep parabolic dish?
> Corner reflector? A twenty-something elemet Yagi? At a distance, the
> signal
> dispersion will certainly not only hit the transmission line but the GPS
> antenna and possibly the receiver as well. Remember the microwave signal
> reflects from nearby objects as well and can cause a change in the wave
> propagation path.
>
> There are numerous papers and articles on GPS jamming and interference.
> Again, take a look at NIST archive. You will be delighted when reading
> about
> unintentional interference to GPS because of loose connectors in the RF
> chain.
>
> Thank you.
>
>
> Regards,
>
>
>
> Edgardo Molina
> Dirección IPTEL
>
> www.iptel.net.mx
>
> T : 55 55 55202444
> M : 04455 10045822
>
> Piensa en Bits SA de CV
>
>
>
> Información anexa:
>
>
>
>
> CONFIDENCIALIDAD DE INFORMACION
>
> Este mensaje tiene carácter confidencial. Si usted no es el destinarario
> de
> este mensaje, le suplicamos se lo notifique al remitente mediante un
> correo
> electrónico y que borre el presente mensaje y sus anexos de su
> computadora
> sin retener una copia de los mismos. Queda estrictamente prohibido
> copiar
> este mensaje o hacer usode el para cualquier propósito o divulgar su en
> forma parcial o total su contenido. Gracias.
>
>
> NON-DISCLOSURE OF INFORMATION
>
> This email is strictly confidential and may also be privileged. If you
> are
> not the intended recipient please immediately advise the sender by
> replying
> to this e-mail and then deleting the message and its attachments from
> your
> computer without keeping a copy. It is strictly forbidden to copy it or
> use
> it for any purpose or disclose its contents to any third party. Thank
> you.
>
>
>
>
>
>
> On Dec 3, 2012, at 11:32 AM, "dlewis6767" 
> wrote:
>
>> I agree, Bob.
>>
>> Like the billboard on the side of the highway says: - Does Advertising
> Work? JUST DID -
>>
>> The bad guys can read this list same as the good guys.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> From: "Bob Camp" 
>> Sent: Monday, December 03, 2012 11:18 AM
>> To: "'Discussion of precise time and frequency measurement'"
> 
>> Subject: Re: [time-nuts] Time security musing - attacking the clock
>> itself
>>
>>> Hi
>>>
>>> One very basic question might be - is a public list read by millions
>>> of
>>> people the right place to dig into this?
>>>
>>> The most basic thing you can detect is "time went backwards".
>>> Obviously,
> it
>>> should never to this. Because it's easy to detect, I'd assume that
>>> the
>>> attacker isn't going to do anything gross. Instead they would try to
> steer
>>> the clock so it slowly goes out of step with the real world.
>>>
>>> If that's correct, then the answer to most of the rest of the
>>> questions
> is
>>> no. A small frequency offset is adequate to do the steer. That sort
>>> of
>>> offset isn't going to mess up things like ADC's and com ports. A
> microsecond
>>> per second slip is a 1 ppm frequency offset. There's nothing in a off
>>> the
>>> shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other
> than
>>> the real time

Re: [time-nuts] PTTI 2012, part 2

[Poul-Henning Kamp]

In message , "Tom Van Baak" writes:

>- USNO rubidium fountains
>
>While many national labs have developed cesium fountains (for
>accuracy), USNO has been gradually building rubidium fountain clocks
>(for stability) and 4 of them are now fully operational. The ADEV
>of these clocks gets well under 1e-16. The paper will have all the
>details but the note I made was that with 20 months of data, the
>stability was near 5e-17 at tau 4 months. That's 100x better than
>a commercial cesium standard; better than all of USNO's other 70
>cesium clocks and 15 H-masers combined. Yes, I've added "rubidium
>fountain" to my automated eBay searches.

I happened to miss a turn (or something...) and stumbled into the
building where they keep those fountains when I visited USNO some
months ago.  WhatI found most remarkable about them were how compact
they were, I still expected fountains to be room size, but these
were rack-sized.

I asked what the material cost would be and if a competent amateur
would be able to do something like that, and the clear message was
that the single biggest problem was the vacuum for a vessel that
size (when you can't use ferromagmnetic materials) and getting
the optical bench calibrated.  "Apart from that it's just some
plumbing"

>- Loran/UrsaNav
>
>CW instead of very low duty cycle Loran pulses would improve S/N [...]

Actually, it probably will not.

The one smart thing about the LORAN signal is S/N, which means that
LORAN for timing purposes is incredible insensitive to noise and
at the same time, incredible transmitter power economy.

The one caveat is that the GRI has to be a good number, preferably
a four (or more!) digit prime number.

(You need to grok moduls-arithmetic to really appreciate this, but
its the magnitude of the prime factors of the product of the GRI
and the disturbing CW which counts:  The smaller the are, the harder
it is to filter the CW-RFI out.)

This is why Europe switched to 4-digit GRIs and almost totally solved
CW-RFI by doing so, and why the Russian Chayka at GRI 8000 is totally
useless near anything resembling a transmitter.


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Scott McGrath]

All of these attacks the clock would notice and probably go into holdover   So 
far these attacks do not allow the time product to be altered in a 
deterministic manner

Sent from my iPhone

On Dec 3, 2012, at 1:46 PM, "Don Latham"  wrote:

> Well, if it's the current set of ruffians we're worried about, my guess
> is a reasonably well-placed RPG would get the job done <1/2 :-)>.
> Don L
> 
> Bob Camp
>> Hi
>> 
>> If your GPS is sitting somewhere on the main power grid, it's often
>> already
>> in a pretty massive electromagnet field. Early on they tried lower
>> frequency
>> time sources and simply could not hear them above the noise of the power
>> plant or switching station. There are multiple papers from the 1970's
>> and
>> 80's going into this.
>> 
>> Bob
>> 
>> -Original Message-
>> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
>> Behalf Of Edgardo Molina
>> Sent: Monday, December 03, 2012 1:11 PM
>> To: Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Time security musing - attacking the clock
>> itself
>> 
>> Dear Erich,
>> 
>> I will allow myself to comment briefly on the RF part of your concerns.
>> 
 * Random thought - Can I point a highly directed microwave beam at
 the
>> coax
 from the GPS antenna to the clock to cause noise inside that channel?
>> 
>> 
>> GPS signals are very low level as we all know and are subject to jamming
>> either intentional or accidental as you are wondering with your
>> microwave
>> signal towards the transmission line. I bet that the majority of the
>> interfering signal will be picked up by the GPS antenna and not by the
>> transmission line. But if the transmission line has nicks, loose
>> couplings
>> or poor shield quality, it will definitely allow the interfering signal
>> to
>> come into the receiver. As a matter of fact, let me ask you this. How
>> concentrated a microwave signal can practically be to cause the damage
>> pointing it to a specific element of the RF chain from a distance? 1º,3º
>> or
>> 10º  in the H-V radiation patterns? What kind of antenna design would be
>> practical for this radiation pattern generation? A deep parabolic dish?
>> Corner reflector? A twenty-something elemet Yagi? At a distance, the
>> signal
>> dispersion will certainly not only hit the transmission line but the GPS
>> antenna and possibly the receiver as well. Remember the microwave signal
>> reflects from nearby objects as well and can cause a change in the wave
>> propagation path.
>> 
>> There are numerous papers and articles on GPS jamming and interference.
>> Again, take a look at NIST archive. You will be delighted when reading
>> about
>> unintentional interference to GPS because of loose connectors in the RF
>> chain.
>> 
>> Thank you.
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Edgardo Molina
>> Dirección IPTEL
>> 
>> www.iptel.net.mx
>> 
>> T : 55 55 55202444
>> M : 04455 10045822
>> 
>> Piensa en Bits SA de CV
>> 
>> 
>> 
>> Información anexa:
>> 
>> 
>> 
>> 
>> CONFIDENCIALIDAD DE INFORMACION
>> 
>> Este mensaje tiene carácter confidencial. Si usted no es el destinarario
>> de
>> este mensaje, le suplicamos se lo notifique al remitente mediante un
>> correo
>> electrónico y que borre el presente mensaje y sus anexos de su
>> computadora
>> sin retener una copia de los mismos. Queda estrictamente prohibido
>> copiar
>> este mensaje o hacer usode el para cualquier propósito o divulgar su en
>> forma parcial o total su contenido. Gracias.
>> 
>> 
>> NON-DISCLOSURE OF INFORMATION
>> 
>> This email is strictly confidential and may also be privileged. If you
>> are
>> not the intended recipient please immediately advise the sender by
>> replying
>> to this e-mail and then deleting the message and its attachments from
>> your
>> computer without keeping a copy. It is strictly forbidden to copy it or
>> use
>> it for any purpose or disclose its contents to any third party. Thank
>> you.
>> 
>> 
>> 
>> 
>> 
>> 
>> On Dec 3, 2012, at 11:32 AM, "dlewis6767" 
>> wrote:
>> 
>>> I agree, Bob.
>>> 
>>> Like the billboard on the side of the highway says: - Does Advertising
>> Work? JUST DID -
>>> 
>>> The bad guys can read this list same as the good guys.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> From: "Bob Camp" 
>>> Sent: Monday, December 03, 2012 11:18 AM
>>> To: "'Discussion of precise time and frequency measurement'"
>> 
>>> Subject: Re: [time-nuts] Time security musing - attacking the clock
>>> itself
>>> 
 Hi
 
 One very basic question might be - is a public list read by millions
 of
 people the right place to dig into this?
 
 The most basic thing you can detect is "time went backwards".
 Obviously,
>> it
 should never to this. Because it's easy to detect, I'd assume that
 the
 attacker isn't going to do anything gross. Instead they would try to
>> steer
 the clock so it slowly goes out of s

Re: [time-nuts] Time security musing - attacking the clock itself

[Bob Camp]

Hi

The key words there being "so far". 

If:

1) You can flood the antenna with a synthetic signal ( = come up with RF
power)
2) You can synthesize synthetic sat signals ( = buy fancy signal generators
)
3) You can walk those signals "off" ( = do some complicated math )

I believe that given enough money, you can do all three (and cover a couple
of minor things as well). It's not at all clear you can do all three without
attracting a *lot* of attention. It's also not clear that it's the most cost
effective approach. 

One simple example:

Fire up the generators. 
GPSDO looses lock and goes into holdover. 
Keep things running. 
GPSDO gets lock and downloads data from your new sats.
You are now in control. 

Far more complex that a noise jammer. Much easier for the good guys to spot
and take care of. Likely not what your local crazy is going to do.

Bob

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Scott McGrath
Sent: Monday, December 03, 2012 2:28 PM
To: Discussion of precise time and frequency measurement
Cc: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Time security musing - attacking the clock itself

All of these attacks the clock would notice and probably go into holdover
So far these attacks do not allow the time product to be altered in a
deterministic manner

Sent from my iPhone

On Dec 3, 2012, at 1:46 PM, "Don Latham"  wrote:

> Well, if it's the current set of ruffians we're worried about, my guess
> is a reasonably well-placed RPG would get the job done <1/2 :-)>.
> Don L
> 
> Bob Camp
>> Hi
>> 
>> If your GPS is sitting somewhere on the main power grid, it's often
>> already
>> in a pretty massive electromagnet field. Early on they tried lower
>> frequency
>> time sources and simply could not hear them above the noise of the power
>> plant or switching station. There are multiple papers from the 1970's
>> and
>> 80's going into this.
>> 
>> Bob
>> 
>> -Original Message-
>> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
>> Behalf Of Edgardo Molina
>> Sent: Monday, December 03, 2012 1:11 PM
>> To: Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Time security musing - attacking the clock
>> itself
>> 
>> Dear Erich,
>> 
>> I will allow myself to comment briefly on the RF part of your concerns.
>> 
 * Random thought - Can I point a highly directed microwave beam at
 the
>> coax
 from the GPS antenna to the clock to cause noise inside that channel?
>> 
>> 
>> GPS signals are very low level as we all know and are subject to jamming
>> either intentional or accidental as you are wondering with your
>> microwave
>> signal towards the transmission line. I bet that the majority of the
>> interfering signal will be picked up by the GPS antenna and not by the
>> transmission line. But if the transmission line has nicks, loose
>> couplings
>> or poor shield quality, it will definitely allow the interfering signal
>> to
>> come into the receiver. As a matter of fact, let me ask you this. How
>> concentrated a microwave signal can practically be to cause the damage
>> pointing it to a specific element of the RF chain from a distance? 1º,3º
>> or
>> 10º  in the H-V radiation patterns? What kind of antenna design would be
>> practical for this radiation pattern generation? A deep parabolic dish?
>> Corner reflector? A twenty-something elemet Yagi? At a distance, the
>> signal
>> dispersion will certainly not only hit the transmission line but the GPS
>> antenna and possibly the receiver as well. Remember the microwave signal
>> reflects from nearby objects as well and can cause a change in the wave
>> propagation path.
>> 
>> There are numerous papers and articles on GPS jamming and interference.
>> Again, take a look at NIST archive. You will be delighted when reading
>> about
>> unintentional interference to GPS because of loose connectors in the RF
>> chain.
>> 
>> Thank you.
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Edgardo Molina
>> Dirección IPTEL
>> 
>> www.iptel.net.mx
>> 
>> T : 55 55 55202444
>> M : 04455 10045822
>> 
>> Piensa en Bits SA de CV
>> 
>> 
>> 
>> Información anexa:
>> 
>> 
>> 
>> 
>> CONFIDENCIALIDAD DE INFORMACION
>> 
>> Este mensaje tiene carácter confidencial. Si usted no es el destinarario
>> de
>> este mensaje, le suplicamos se lo notifique al remitente mediante un
>> correo
>> electrónico y que borre el presente mensaje y sus anexos de su
>> computadora
>> sin retener una copia de los mismos. Queda estrictamente prohibido
>> copiar
>> este mensaje o hacer usode el para cualquier propósito o divulgar su en
>> forma parcial o total su contenido. Gracias.
>> 
>> 
>> NON-DISCLOSURE OF INFORMATION
>> 
>> This email is strictly confidential and may also be privileged. If you
>> are
>> not the intended recipient please immediately advise the sender by
>> replying
>> to this e-mail and then deleting the message and its attac

Re: [time-nuts] Time security musing - attacking the clock itself

[Erich Heine]

On Mon, Dec 3, 2012 at 11:18 AM, Bob Camp  wrote:

> Hi
>
> One very basic question might be - is a public list read by millions of
> people the right place to dig into this?
>
>
Thanks for bringing this up. I probably should have asked the list about
general comfort levels regarding such a discussion first. My apologies for
such an oversight.

I personally hold the view that such discussions are necessary, if tempered
with a spirit of responsible disclosure. By this I mean public discourse
over general attack and defense techniques is a good thing, in that it
allows the "good guys" the chance to work in solutions and defenses, and
that it keeps engineers informed as to what not to do in their designs.
 Specific attacks (e.g. Device X has software bug Y allowing $Algorithm to
cause $Result) should be reported to the vendor quietly to allow them to
fix it, and once a fix is available, it should be publicly disclosed to
allow people informed decision on upgrades and mitigation, as well as to
provide understanding and examples for future defenders.

The flip side of this is that the bad guys also get access to it. General
IT experience however is that there are usually already bad guys thinking
about that class of attacks, or already exploiting them by the time
defenders start looking into them.

All of that being said, I should mention, that if people are uncomfortable
with this style of discussion on this list, I would be glad to take it off
list. Similarly if anyone wants to discuss such things in a more private
manner, feel free to contact me individually at either the adress I use for
the list, or my university email: ehe...@illinois.edu



> The most basic thing you can detect is "time went backwards". Obviously, it
> should never to this. Because it's easy to detect, I'd assume that the
> attacker isn't going to do anything gross. Instead they would try to steer
> the clock so it slowly goes out of step with the real world.
>
> If that's correct, then the answer to most of the rest of the questions is
> no. A small frequency offset is adequate to do the steer. That sort of
> offset isn't going to mess up things like ADC's and com ports. A
> microsecond
> per second slip is a 1 ppm frequency offset. There's nothing in a off the
> shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other than
> the real time clock..).
>

Oh sure, in a desktop this is true, but the sensors I am talking about do
have requirements that are more strict - they generally run and RTOS and
have decent clocks in them to begin with. In a 60Hz power system, a few
microseconds is enough to cause synchronized point-on-wave measurements to
report differences of the type that require corrective action. Similarly
frequency oscillations (frequency of the AC power wave that is measured)
reported by steering a clock to slightly faster then slightly slower on a
regular basis could cause inefficient (that is expensive) precautionary
measures to be taken. So clock steering is a good thing for me to know more
about I think. Thanks for the pointer!


>
> One hundred microseconds per second is plenty of slip to get things into an
> odd state. By the end of 24 hours, you would be off by 8.64 seconds.
>
> Bob
>
> -Original Message-
> From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
> Behalf Of Erich Heine
> Sent: Monday, December 03, 2012 11:30 AM
> To: Discussion of precise time and frequency measurement
> Subject: [time-nuts] Time security musing - attacking the clock itself
>
> One of my favorite things about being in security, (and a researcher in
> general), is that we regularly get to say "that sounds too hard, what if we
> look $HERE instead". So while I catch up on security in the time
> synchronization space, I've also been musing on this notion of attacking
> the clock. By this I mean I am going to assume the protocols for
> synchronization are secure and instead look at other things which can
> affect measurement timestamping.
>
> I also am going to assume that an attacker doesn't just want to bring down
> any system dependent on compromised devices, but rather wants to cause
> instabilities, inefficiencies and other long-term damage (for whatever
> reasons - economic, political, revenge, whatever - a good attack is
> frequently one that doesn't bring down a system, but instead makes it
> untrustworthy and is hard to eradicate).
>
> In my space (power grid) there is a lot of work being done to get good
> synchronized measurement of the whole wide-area system. This of course
> depends on trusting the clock. Many calculations of state, and problem
> detection (e.g. various forms of oscillation) implicitly trust the
> measurement is accurate within defined error bands, including time.
>
> What I've learned from reading this list is that clocks are pretty
> sensitive - a lot of factors can affect the reliability (and hence
> trustworthiness) of the reported time.
>
> So what I am trying to understa

Re: [time-nuts] Using a frequency synthesizer replacement for motherboard oscillator

[Tom Van Baak]

> My research group has had some good experiences using products from Endace (
> http://www.endace.com/) for network timing measurement at the ethernet
> level. I don't have a pointer immediately to the work, but if there is
> interest can ask tomorrow at work. The gist of it though was to understand

Hi Erich,

You are welcome to post your experiences with synchronization or network timing 
measurements on the list or to solicit methods to time packets to the 
microsecond or nanosecond. The rest of your agenda is straying far off-topic 
and you need to find or create a forum elsewhere. It appears you have misread 
the focus of this group.

Please re-read the intro page (leapsecond.com/time-nuts.htm) or the archives 
(www.febo.com/pipermail/time-nuts/). If you have questions contact me directly.

Thanks,
/tvb


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[lists]

Or you just hack the SCADA. Far nastier.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Hal Murray]

sophac...@gmail.com said:
> So what I am trying to understand today is ways we can affect the
> reliability of the clock, having affects on everything mentioned above. 

There is a big overlap between maliciously attacking the clock and the clock 
doing something crazy due to bugs in hardware, firmware, software, or wetware 
(people/operations).

If I was working in that area, I think the first step would be to collect a 
data base of interesting events to make a checklist of things to think about 
and/or feed to regression testing.

I don't know much about power grid control.  Is there a good overview web 
page?

What level of time accuracy do you need?  ms? us?  Do you need absolute 
accuracy or just stability?

What sort of network environment are you using?  Are you on a well run 
lightly loaded private net or running on the big bad internet?  What sort of 
OSes are you using?  Does each control room have it's own good source of time 
(local GPS) or do some of them get time over the net?

--

> * Is the method for reading the clock a directly wired GPIO pin, or is it on
> a shared bus like I2C or SPI? (If so, other things on the bus could be
> compromised instead to not play nice with bus and affect readings) 

I think you are missing a key idea.

Most OSes maintain the system clock in software.  Once the system is up and 
running, there is no off-chip hardware involved to read-the-clock.  Most 
systems read the RTC/TOY clock once at boot time and use that to initialize 
the internal clock.  Details vary with OS and hardware.

Most modern CPUs have a counter that runs at the CPU clock frequency.  Intel 
calls it the TSC.  If you can adjust the CPU frequency (to save power), there 
is probably some counter that runs at a fixed frequency.  Timekeeping is just 
read that counter and do some math.

Very old systems used to bump the time on every scheduler interrupt.  That 
interrupt often came from the RTC chip.  Not quite so old systems did that, 
but also interpreted between scheduler ticks using the TSC.

The crystal that drives the CPU and/or the calibration software is often off 
by 10s or 100s of ppm.  Most OSes have a system call to adjust the 
calibration factor.  ntpd calls it drift.  This makes a huge difference.

If you have a local PPS source, you can use it and ntpd as a thermometer.
  http://www.ijs.si/time/temp-compensation/

Changes in self heating when the workload changes makes this area very 
interesting.

--

> Specific attacks (e.g. Device X has software bug Y allowing $Algorithm to
> cause $Result) should be reported to the vendor quietly to allow them to fix
> it, and once a fix is available, it should be publicly disclosed to allow
> people informed decision on upgrades and mitigation, as well as to provide
> understanding and examples for future defenders. 

Some vendors have a history of ignoring reports of serious security problems. 
 I think the "allow them to fix it" needs a timeout.

That whole approach assumes that everybody can just blindly install all the 
vendors software updates as soon as they are released.  That's not likely to 
be the procedure in any high reliability environment.


-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Jim Lux]

On 12/3/12 9:32 AM, dlewis6767 wrote:

I agree, Bob.

Like the billboard on the side of the highway says: - Does Advertising
Work? JUST DID -

The bad guys can read this list same as the good guys.




Security through obscurity never works in the long run.  Much better to 
discuss vulnerabilities in the open, and discuss countermeasures that 
are robust.



Clock synchronization is of great interest in a variety of crypto 
systems where keys are changed on a predetermined schedule (the RSA two 
factor authentication key fob is an interesting instance).


It's even trickier when you have to distribute "time" in a secure way 
(in the sense that not only is the "at the tone, the time is" message is 
reliable, but also that the timing of the "tone" is reliable).


The various redundancy and reasonableness checks (e.g. for GPS) are in 
this area as well.


The question is: "Can I distribute timing information through a network 
reliably"



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[lists]

I have one of those key fobs. Does the code somehow inform the power the be 
about the drift in the built in clock? Or is the time element of the code so 
sloppy that the drift is acceptable?


-Original Message-
From: Jim Lux 
Sender: time-nuts-boun...@febo.com
Date: Mon, 03 Dec 2012 15:45:24 
To: 
Reply-To: Discussion of precise time and frequency measurement

Subject: Re: [time-nuts] Time security musing - attacking the clock itself

On 12/3/12 9:32 AM, dlewis6767 wrote:
> I agree, Bob.
>
> Like the billboard on the side of the highway says: - Does Advertising
> Work? JUST DID -
>
> The bad guys can read this list same as the good guys.
>
>

Security through obscurity never works in the long run.  Much better to 
discuss vulnerabilities in the open, and discuss countermeasures that 
are robust.


Clock synchronization is of great interest in a variety of crypto 
systems where keys are changed on a predetermined schedule (the RSA two 
factor authentication key fob is an interesting instance).

It's even trickier when you have to distribute "time" in a secure way 
(in the sense that not only is the "at the tone, the time is" message is 
reliable, but also that the timing of the "tone" is reliable).

The various redundancy and reasonableness checks (e.g. for GPS) are in 
this area as well.

The question is: "Can I distribute timing information through a network 
reliably"


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] GPSDO Alternatives

[Tom Clifton]

While the Trimble Tbolts are still out there and reasonably available, are 
there any newer alternatives in the same general price range?  
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Scott McGrath]

I think this class of attack would be directed along the order of financial 
crimes or industrial espionage where you want to hide the audit trail or 
convince a database that the update is legitimate 

We really need to think more about the secure distribution of time products 

In the past in prior incarnations I have offered multiple time products some 
secure others not

Sent from my iPhone

On Dec 3, 2012, at 5:22 PM, li...@lazygranch.com wrote:

> Or you just hack the SCADA. Far nastier.
> 
> 
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO Alternatives

[Bob Camp]

Hi

The TBolt is the newest of the used category. For newer, you skip up to brand 
new.

Bob

On Dec 3, 2012, at 7:42 PM, Tom Clifton  wrote:

> While the Trimble Tbolts are still out there and reasonably available, are 
> there any newer alternatives in the same general price range?  
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Chris Albertson]

On Mon, Dec 3, 2012 at 4:51 PM, Scott McGrath  wrote:

>
>
> We really need to think more about the secure distribution of time products
>

Is NTP not secure.  I know it can be secured but I think in practice people
disable passwords.



-- 

Chris Albertson
Redondo Beach, California
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO Alternatives

[paul swed]

Hmmm new and better.
That means better stability, noise, lower power, lower heat, for less and
works with lady heather? :-)
I can hope.
Regards
Paul
WB8TSL

On Mon, Dec 3, 2012 at 7:52 PM, Bob Camp  wrote:

> Hi
>
> The TBolt is the newest of the used category. For newer, you skip up to
> brand new.
>
> Bob
>
> On Dec 3, 2012, at 7:42 PM, Tom Clifton  wrote:
>
> > While the Trimble Tbolts are still out there and reasonably available,
> are there any newer alternatives in the same general price range?
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO Alternatives

[Magnus Danielson]

On 12/04/2012 02:44 AM, paul swed wrote:

Hmmm new and better.
That means better stability, noise, lower power, lower heat, for less and
works with lady heather? :-)
I can hope.


Mostly cheaper actually. Better GPS to start with, probably. Lower 
power, most probably.


We should discuss if we can't have Lady Heather take a larger 
client-base of GPSDOs. There are so many peaces in there that would be 
nice to be used with a larger set of tools, like G12, Z12s, Z3801/3815 etc.


Cheers,
Magnsu

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Edgardo Molina]

NTP is not secure in nature. MD5 key exchange between client and server is the 
only secure feature up to now, for the client to be sure that he/she is getting 
a correct time sync to the desired server. On the other side if the server does 
not receive a matching MD5 key, it will simply ignore the petition. Beside 
that, NTP is a connectionless UDP service, it is based in the open exchange of 
data, not establishing a session like other protocols that use TCP. This eases 
the transfer of information but makes it difficult to set controls to the 
process.

On the other hand PTP is evolving to be a future protocol for time transfer. 
Nowadays it is superior than NTP in the LAN environment. 

Regards,



Edgardo Molina
Dirección IPTEL

www.iptel.net.mx

T : 55 55 55202444
M : 04455 10045822

Piensa en Bits SA de CV



Información anexa:




CONFIDENCIALIDAD DE INFORMACION

Este mensaje tiene carácter confidencial. Si usted no es el destinarario de 
este mensaje, le suplicamos se lo notifique al remitente mediante un correo 
electrónico y que borre el presente mensaje y sus anexos de su computadora sin 
retener una copia de los mismos. Queda estrictamente prohibido copiar este 
mensaje o hacer usode el para cualquier propósito o divulgar su en forma 
parcial o total su contenido. Gracias.


NON-DISCLOSURE OF INFORMATION

This email is strictly confidential and may also be privileged. If you are not 
the intended recipient please immediately advise the sender by replying to this 
e-mail and then deleting the message and its attachments from your computer 
without keeping a copy. It is strictly forbidden to copy it or use it for any 
purpose or disclose its contents to any third party. Thank you.






On Dec 3, 2012, at 7:36 PM, Chris Albertson  wrote:

> On Mon, Dec 3, 2012 at 4:51 PM, Scott McGrath  wrote:
> 
>> 
>> 
>> We really need to think more about the secure distribution of time products
>> 
> 
> Is NTP not secure.  I know it can be secured but I think in practice people
> disable passwords.
> 
> 
> 
> -- 
> 
> Chris Albertson
> Redondo Beach, California
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO Alternatives

[Bob Camp]

Hi

The gotcha is that you go from paying surplus prices to paying new prices. New 
price to new price, they certainly are cheaper. Not so easy to beat a $100 
TBolt on price (if you can find one).

Bob

On Dec 3, 2012, at 8:50 PM, Magnus Danielson  wrote:

> On 12/04/2012 02:44 AM, paul swed wrote:
>> Hmmm new and better.
>> That means better stability, noise, lower power, lower heat, for less and
>> works with lady heather? :-)
>> I can hope.
> 
> Mostly cheaper actually. Better GPS to start with, probably. Lower power, 
> most probably.
> 
> We should discuss if we can't have Lady Heather take a larger client-base of 
> GPSDOs. There are so many peaces in there that would be nice to be used with 
> a larger set of tools, like G12, Z12s, Z3801/3815 etc.
> 
> Cheers,
> Magnsu
> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Hal Murray]

li...@lazygranch.com said:
> I have one of those key fobs. Does the code somehow inform the power the be
> about the drift in the built in clock? Or is the time element of the code so
> sloppy that the drift is acceptable? 

The magic number changes every second or so.  You only have to scan a few 
seconds either side of the correct time to find a valid match.  Every time 
the server gets a match it can update its memory of the fob time to reduce 
its searching in the future.

You could measure/compute the drift too.  I don't know if that's worth the 
effort.  It would probably change with temperature so seasonal or lifestyle 
changes could throw the prediction way off.

[I have no inside knowledge.  I could be totally wrong, but that seems 
reasonable to me.  They may have a better approach.]



-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Lady Heather V3.10, ALARM: 4000

[Stan, W1LE]

Hello The Net:

Any idea what this alarm is ?

It appreared,
I got out of the application,
I restarted, and
no more alarm notification.

Stan, W1LE

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Hal Murray]

albertson.ch...@gmail.com said:
> Is NTP not secure.  I know it can be secured but I think in practice people
> disable passwords. 

The default in most distributions and most servers is no crypto.  So it's not 
that anybody disables authentication but doesn't go through all the work to 
enable it.

NIST has an experimental program to use crypto.
  http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm


-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] GPSDO Alternatives

[paul swed]

Yes sir $139. But boy I have not seen cheap tbolts in  bit. As I recall
$260 these days?

On Mon, Dec 3, 2012 at 9:12 PM, Bob Camp  wrote:

> Hi
>
> The gotcha is that you go from paying surplus prices to paying new prices.
> New price to new price, they certainly are cheaper. Not so easy to beat a
> $100 TBolt on price (if you can find one).
>
> Bob
>
> On Dec 3, 2012, at 8:50 PM, Magnus Danielson 
> wrote:
>
> > On 12/04/2012 02:44 AM, paul swed wrote:
> >> Hmmm new and better.
> >> That means better stability, noise, lower power, lower heat, for less
> and
> >> works with lady heather? :-)
> >> I can hope.
> >
> > Mostly cheaper actually. Better GPS to start with, probably. Lower
> power, most probably.
> >
> > We should discuss if we can't have Lady Heather take a larger
> client-base of GPSDOs. There are so many peaces in there that would be nice
> to be used with a larger set of tools, like G12, Z12s, Z3801/3815 etc.
> >
> > Cheers,
> > Magnsu
> >
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> > and follow the instructions there.
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Harlan Stenn]

What is the 'thing' being secured?

H

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Hal Murray]

xe1...@amsat.org said:
> On the other hand PTP is evolving to be a future protocol for time transfer.
> Nowadays it is superior than NTP in the LAN environment.

"Superior" is an interesting word.

I'm not familiar with the details of current PTP implementations.  I am 
reasonably familiar with the NTP reference package which is shipped with most 
Linux/*BSD distributions and also runs on Windows.  (The Windows default is 
to use SNTP, S for Simple or maybe Stupid.  You have to go out of your way to 
install ntpd on Windows.)

NTP is intended for use in the big bad Internet.  Much of the logic/code in 
ntpd is trying to dance around broken clocks or broken servers or crazy 
networks.  It has a crypto option, but it's not used very often.  (There are 
plenty of problems before you get to one that needs crypto.)

After the classic ntp client-server/request-response exchange, the client has 
4 time stamps.
  When the request left the client.
  When the request arrived at the server.
  When the response left the server.
  When the response arrived back at the client.
The middle two are using the server's clock.  The first and last use the 
clients clock.

The reason that you need 2 server times is that the server may be busy (for 
example doing crypto crunching) or whatever.  Normally both server time 
stamps are very close together.

If you assume that both clocks are accurate, that lets you measure network 
timings in both directions.

NTP assumes the network transit times are symmetrical.  That lets you 
calculate the clock offset.

I have a slow DSL line.  If I start a big download, the queuing delay on my 
DSL line jumps up to a second or so on average.  (lots of noise)  If I go web 
browsing and hit a page with lots of graphics, the queuing delays can almost 
get to 4 seconds.

That basically screws up the symmetrical assumption.  If you are interested 
in this area, you should study and understand this web page:
  http://www.eecis.udel.edu/~mills/ntp/html/huffpuff.html

Clients using NIST servers sometimes see this problem with the other sign.  
They have queuing delays at the input to the server because zillions of 
clients are pounding on the server.  The input (to-server) link sometimes 
gets overloaded, even with 100 megabit Ethernet connections.  (maybe 
faster...)  That's the top edge of the wedge diagram rather than my bottom 
edge.

-

PTP is basically making the network transit times more accurate than 
"symmetrical" by measuring them.  Each box that processes a packet updates 
the packet with the processing/queuing delays.

I think the PTP geeks are working on crypto.  I'm not tracking the details.



-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] Time security musing - attacking the clock

[M. Simon]

A dirty power supply might go unnoticed. Maybe feed in line noise to the LV 
stuff with a HV cap. 

 
The problem is that it is difficult to fool for long people who are paying 
attention.

Simon

Engineering is the art of making what you want from what you can get at a 
profit.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Jim Lux]

On 12/3/12 6:34 PM, Hal Murray wrote:


li...@lazygranch.com said:

I have one of those key fobs. Does the code somehow inform the power the be
about the drift in the built in clock? Or is the time element of the code so
sloppy that the drift is acceptable?


The magic number changes every second or so.


Every 30 seconds or every minute.. I've seen both.  My fob is once a 
minute, the iPhone "soft fob" is 30 seconds.



 You only have to scan a few

seconds either side of the correct time to find a valid match.  Every time
the server gets a match it can update its memory of the fob time to reduce
its searching in the future.


Exactly, the maximum time difference is a settable parameter.



You could measure/compute the drift too.  I don't know if that's worth the
effort.  It would probably change with temperature so seasonal or lifestyle
changes could throw the prediction way off.


I don't think they do that.. I think it's a "reset when validated"...



[I have no inside knowledge.  I could be totally wrong, but that seems
reasonable to me.  They may have a better approach.]



It's all described on the RSA website..


Hmm..  I suspect I could time my fob once a day, and see how many 
seconds a day it drifts.. without a timed camera it would be hard to get 
tighter than 1 second resolution..


the iPhone one almost certainly uses the internal clock in the phone.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] PPS offset between GPS receivers

[Gabs Ricalde]

I'm using a Symmetricom 58534A GPS timing receiver and a GPS board with a
SkyNav SKG25A1 module driving stratum 1 NTP servers.

On one of the servers, the ppstest output while the 58534A is connected
looks like:
source 0 - assert 1354495734.00102
source 0 - assert 1354495735.00040

When I switch the PPS source to the SKG25A1, the ppstest output
indicates the PPS of that receiver is about 2 us early compared to the 58534A:
source 0 - assert 1354495740.97923
source 0 - assert 1354495741.97905

The setup looks like this:
58534A GPS -> 10 m CAT5 cable -> MC3486 RS422 receiver -> GPIO
active antenna -> 3 m cable -> SKG25A1 GPS -> GPIO

Both receivers were factory reset before the test.
I'm planning on getting another GPS receiver to check which receiver
is at fault. Has anyone found timing differences this large with their
GPS receivers?

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Hal Murray]

jim...@earthlink.net said:
> The question is: "Can I distribute timing information through a network
> reliably"

I think so.  The better question is how accurately?

Assume client and server share a secret key and the server is trustworthy.  
Assume the protocol allows the client to put a magic number (nonce) in the 
packet.

All the bad-guy can do is delay and/or replay packets.  Everything else gets 
rejected by the crypto layer.

It's easy for the client to discard duplicate answers.  That leaves us with 
just the problem of processing delayed packets.

The client can measure the round-trip-time.  That translates into how-accurate.

If the bad-guy delays client-to-server packets (requests), the time will be off 
in one direction.  If the bad-guy delays server-client packets (responses), the 
clock will be off in the other direction.



-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] PPS offset between GPS receivers

[Tom Van Baak]

Hi Gabs, and welcome to the list.

Or, the 58534A is 2 us late compared to the SKG25A1. If you have a 'scope handy 
check the risetime of the signal at all points in the long chain from the 
58534A to the GPIO.

Better yet, if you have a dual-channel 'scope or TI counter, compare the 1PPS's 
as close as possible to each GPS receiver. You can also use two channels to 
view the propagation delay along the signal path.

A third GPS receiver may help as well, or it could add a third variable.

/tvb

> I'm using a Symmetricom 58534A GPS timing receiver and a GPS board with a
> SkyNav SKG25A1 module driving stratum 1 NTP servers.
> 
> On one of the servers, the ppstest output while the 58534A is connected
> looks like:
> source 0 - assert 1354495734.00102
> source 0 - assert 1354495735.00040
> 
> When I switch the PPS source to the SKG25A1, the ppstest output
> indicates the PPS of that receiver is about 2 us early compared to the 58534A:
> source 0 - assert 1354495740.97923
> source 0 - assert 1354495741.97905
> 
> The setup looks like this:
> 58534A GPS -> 10 m CAT5 cable -> MC3486 RS422 receiver -> GPIO
> active antenna -> 3 m cable -> SKG25A1 GPS -> GPIO
> 
> Both receivers were factory reset before the test.
> I'm planning on getting another GPS receiver to check which receiver
> is at fault. Has anyone found timing differences this large with their
> GPS receivers?



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[gary]

I was a bit concerned about clicking the fob for no good reason. I 
assume each click is a different number. I only use it for ebay and 
paypal. [Incidentally, they jacked the price from $5 to $30.]


Now a phone has accurate network time, so they could get really tricky 
with the time as part of the code.


I was meditating a bit on the power grid synchronization. If all the 
sites but one are in sync, then the generator whose sync is being hacked 
will have a hard time trying to feed the grid while being out of phase. 
This should be detectable electronically in the generator interface. If 
the timing is moved slowly, the the "conflict" would build slowly as well.


In the dark ages, I TAs an electronics class set up for non electrical 
engineers. I considered it kind of brutal since they tried to cover just 
about everything in one class. Well it included what we used to call 
"motors and rotors". [I suspect this isn't even taught anymore.] One of 
the lab experiments was to sync a generator to the mains. Now the 
generator was driven by a motor from the mains, so this wasn't 
particularly difficult. You would put a meter between your generator and 
the mains and drag on the shaft a bit until the phase error was zero, 
then turn the switch to connect them.


Things were going OK but then I heard a nasty sound and the lights 
flickered a bit. It turns out some curious students wanted to see what 
happened if the generator and mains were out of phase. Well, the mains wins.


It is apparently hard to move the grid.




On 12/3/2012 8:12 PM, Jim Lux wrote:

On 12/3/12 6:34 PM, Hal Murray wrote:


li...@lazygranch.com said:

I have one of those key fobs. Does the code somehow inform the power
the be
about the drift in the built in clock? Or is the time element of the
code so
sloppy that the drift is acceptable?


The magic number changes every second or so.


Every 30 seconds or every minute.. I've seen both.  My fob is once a
minute, the iPhone "soft fob" is 30 seconds.


  You only have to scan a few

seconds either side of the correct time to find a valid match.  Every
time
the server gets a match it can update its memory of the fob time to
reduce
its searching in the future.


Exactly, the maximum time difference is a settable parameter.



You could measure/compute the drift too.  I don't know if that's worth
the
effort.  It would probably change with temperature so seasonal or
lifestyle
changes could throw the prediction way off.


I don't think they do that.. I think it's a "reset when validated"...



[I have no inside knowledge.  I could be totally wrong, but that seems
reasonable to me.  They may have a better approach.]



It's all described on the RSA website..


Hmm..  I suspect I could time my fob once a day, and see how many
seconds a day it drifts.. without a timed camera it would be hard to get
tighter than 1 second resolution..

the iPhone one almost certainly uses the internal clock in the phone.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.



___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Sanjeev Gupta]

On Tue, Dec 4, 2012 at 1:59 PM, gary  wrote:

> Things were going OK but then I heard a nasty sound and the lights
> flickered a bit. It turns out some curious students wanted to see what
> happened if the generator and mains were out of phase. Well, the mains wins.
>

Been there, done that (as the student).


> It is apparently hard to move the grid.
>

Yes, and getting a pass grade after that is _very_ difficult.  Being put on
the list of students who have to do Labs but are not allowed to touch
anything ...

Luckily I was "studying" Civil Engineering, and this was a required 1
semester course "Electrical and Electronic Engineering".  Everything in 11
weeks.  And the Profs know they are never going to see you again, so they
shudder, roll their eyes, and try to ignore the idiots on the benches.

-- 
Sanjeev Gupta
+65 98551208 http://www.linkedin.com/in/ghane
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Hal Murray]

li...@lazygranch.com said:
> Now a phone has accurate network time, so they could get really tricky  with
> the time as part of the code. 

Are you sure?

I don't have a smart phone, but I've heard various war stories of crappy time 
keeping.

I assume the time was coming from an ap rather than the local cell tower.


-- 
These are my opinions.  I hate spam.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[gary]

All my blackberries synced to the network. I presume all phones do this. 
I still have an Android HTC G2 that has a NTP app, not that it ever worked!



On 12/3/2012 10:27 PM, Hal Murray wrote:


li...@lazygranch.com said:

Now a phone has accurate network time, so they could get really tricky  with
the time as part of the code.


Are you sure?

I don't have a smart phone, but I've heard various war stories of crappy time
keeping.

I assume the time was coming from an ap rather than the local cell tower.




___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Tom Van Baak]

Please. May we call this thread finished. It's way off topic.

Thanks,
/tvb


___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Time security musing - attacking the clock itself

[Jonatan Walck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/04/2012 04:44 AM, Hal Murray wrote:
> 
> 
> PTP is basically making the network transit times more accurate
> than "symmetrical" by measuring them.  Each box that processes a
> packet updates the packet with the processing/queuing delays.
> 
> I think the PTP geeks are working on crypto.  I'm not tracking the
> details.
> 

We're shifting slightly off topic here, apologies in advance. As far
as I know PTP cannot calculate link asymmetry, even though it does
indeed take delays in switches/routers into account if they are
IEEE1588-aware by updating timestamps en route.

IEEE1588-2008 can compensate for link asymmetry too, but have no way
of calculating it. That is to say, something else has to give input
telling PTP the characteristics of the link asymmetry. This is
measurable in a static local network but is a hopeless task over Internet.

I've seen some trials of using IPSec to protect PTP-traffic from
tampering/manipulation, and I think there has been extensions tested
similar to those used in NTP but I haven't seen those in IEEE1588.
Using the approaches of NTP applied directly to PTP is hopeless with a
IEEE1588-aware network though, all checksums will fail given that the
path actively prods around in the packet like a true MITM (one can
only hope these men in the middle are friendly:).

I found a possibly good read on IETF tictoc re: security requirements
for PTP and NTP for those who want to learn how deep the rabbit hole
goes.[1] As Harlan Stenn pointed out in another part of the thread, we
have to know what we're protecting ourselves against before we start
to throw in counter-measures.

// jwalck

[1]:
https://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-03
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQvatYAAoJEFwg9i9GDX+ncQcP/A/ZWMKZAnWaapr1gfDMsLmd
UuNLjrxw3uJSpvGTmBI3+W1C2bYl88laTZWQWPUFpW5R/PLxFZwuA3FlNKQwzI5S
Adyo3Kzhk7ukbYvSULFyhQTnGMLLSx3kmzy4abln47/olft63SWhh0QTKvNeeQXl
8r21xvUlr7cBA+lGv0+P253SCFAcgn1V2ViCx8oHioWrjtxE1xB2mquU5ieGMPzA
L/KMzvkWakwPm/pNeKNuUCh8uP/FvybaqXhm9NcA/GswdzU5+xgSDpeS0cC1LEuo
G7rk2WazFgghKaCGF/HILsBXZ2eWRiI5XbOBgi2T3qSUur4Qo1K+ZJuZc464/ARE
hdsiN1o3f5LCNKFyCUQnjOOr0Oe26NGeA9jEDKMtlRWqAaudxOR2EnArDu3rSCe5
gDgmHq2ysBP5wUQrRa6OBIU/kQsLOFYOtdRKIQgfq2nOA96t1NblglXTkGv7zSDz
ujnpMtAvVCNsC5d9ialDLID8bLEfQnBzfR/jmHXVxXoEc/d+GoLjTZ6sdlfyFqet
jqRXtUER4PmQBEeac9Tlof9qQFmdQOWpjgV0YwfqIJ/9TB9zgpbGYeDDNEdyr0h6
MobJKpbedKrYhBlZyAvYAg6IB4Ad0W8+nBHO2XQ8YAWtVVXo27r7nN6wqnq+BZRz
LEWmpz7gSolJWlaby/Sr
=wdso
-END PGP SIGNATURE-

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.