EH
Erich Heine
Mon, Dec 3, 2012 4:29 PM
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:
- 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?
- 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?
- 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
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
BC
Bob Camp
Mon, Dec 3, 2012 5:18 PM
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-bounces@febo.com [mailto:time-nuts-bounces@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:
- 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?
- 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?
- 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.
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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
D
dlewis6767
Mon, Dec 3, 2012 5:32 PM
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" lists@rtty.us
Sent: Monday, December 03, 2012 11:18 AM
To: "'Discussion of precise time and frequency measurement'"
time-nuts@febo.com
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-bounces@febo.com [mailto:time-nuts-bounces@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:
- 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?
- 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?
- 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.
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.
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" <lists@rtty.us>
Sent: Monday, December 03, 2012 11:18 AM
To: "'Discussion of precise time and frequency measurement'"
<time-nuts@febo.com>
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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>
>
>
> _______________________________________________
> 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.
SM
Scott McGrath
Mon, Dec 3, 2012 5:53 PM
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" dlewis6767@austin.rr.com 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" lists@rtty.us
Sent: Monday, December 03, 2012 11:18 AM
To: "'Discussion of precise time and frequency measurement'" time-nuts@febo.com
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-bounces@febo.com [mailto:time-nuts-bounces@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:
- 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?
- 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?
- 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.
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.
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" <dlewis6767@austin.rr.com> 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" <lists@rtty.us>
> Sent: Monday, December 03, 2012 11:18 AM
> To: "'Discussion of precise time and frequency measurement'" <time-nuts@febo.com>
> 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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>>
>>
>>
>> _______________________________________________
>> 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.
EM
Edgardo Molina
Mon, Dec 3, 2012 6:11 PM
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" dlewis6767@austin.rr.com 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" lists@rtty.us
Sent: Monday, December 03, 2012 11:18 AM
To: "'Discussion of precise time and frequency measurement'" time-nuts@febo.com
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-bounces@febo.com [mailto:time-nuts-bounces@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:
- 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?
- 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?
- 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.
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.
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" <dlewis6767@austin.rr.com> 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" <lists@rtty.us>
> Sent: Monday, December 03, 2012 11:18 AM
> To: "'Discussion of precise time and frequency measurement'" <time-nuts@febo.com>
> 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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>>
>>
>>
>> _______________________________________________
>> 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.
BC
Bob Camp
Mon, Dec 3, 2012 6:28 PM
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-bounces@febo.com [mailto:time-nuts-bounces@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
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" dlewis6767@austin.rr.com wrote:
I agree, Bob.
Like the billboard on the side of the highway says: - Does Advertising
The bad guys can read this list same as the good guys.
From: "Bob Camp" lists@rtty.us
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,
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
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
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
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
the real time clock..).
One hundred microseconds per second is plenty of slip to get things into
odd state. By the end of 24 hours, you would be off by 8.64 seconds.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@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
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
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:
- I am an attacker. I can get remote root access to a device that
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
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
(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
in off the network. What sort of modifications to the code of that
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?
- 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
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?
- I have a long planning horizon, and access to the devices at some
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
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
and follow the instructions there.
and follow the instructions there.
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-bounces@febo.com [mailto:time-nuts-bounces@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" <dlewis6767@austin.rr.com> 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" <lists@rtty.us>
> Sent: Monday, December 03, 2012 11:18 AM
> To: "'Discussion of precise time and frequency measurement'"
<time-nuts@febo.com>
> 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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>>
>>
>>
>> _______________________________________________
>> 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.
DL
Don Latham
Mon, Dec 3, 2012 6:46 PM
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-bounces@febo.com [mailto:time-nuts-bounces@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
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" dlewis6767@austin.rr.com
wrote:
I agree, Bob.
Like the billboard on the side of the highway says: - Does Advertising
The bad guys can read this list same as the good guys.
From: "Bob Camp" lists@rtty.us
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,
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
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
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
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
the real time clock..).
One hundred microseconds per second is plenty of slip to get things
into
odd state. By the end of 24 hours, you would be off by 8.64 seconds.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@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
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
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:
- I am an attacker. I can get remote root access to a device that
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
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
(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
in off the network. What sort of modifications to the code of that
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?
- 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
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?
- I have a long planning horizon, and access to the devices at some
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
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
and follow the instructions there.
and follow the instructions there.
--
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell
Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com
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-bounces@febo.com [mailto:time-nuts-bounces@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" <dlewis6767@austin.rr.com>
> 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" <lists@rtty.us>
>> Sent: Monday, December 03, 2012 11:18 AM
>> To: "'Discussion of precise time and frequency measurement'"
> <time-nuts@febo.com>
>> 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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>
>
>
> _______________________________________________
> 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.
>
>
--
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell
Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com
SM
Scott McGrath
Mon, Dec 3, 2012 7:27 PM
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" djl@montana.com 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-bounces@febo.com [mailto:time-nuts-bounces@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
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" dlewis6767@austin.rr.com
wrote:
I agree, Bob.
Like the billboard on the side of the highway says: - Does Advertising
The bad guys can read this list same as the good guys.
From: "Bob Camp" lists@rtty.us
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,
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
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
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
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
the real time clock..).
One hundred microseconds per second is plenty of slip to get things
into
odd state. By the end of 24 hours, you would be off by 8.64 seconds.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@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
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
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:
- I am an attacker. I can get remote root access to a device that
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
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
(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
in off the network. What sort of modifications to the code of that
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?
- 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
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?
- I have a long planning horizon, and access to the devices at some
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
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
and follow the instructions there.
and follow the instructions there.
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" <djl@montana.com> 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-bounces@febo.com [mailto:time-nuts-bounces@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" <dlewis6767@austin.rr.com>
>> 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" <lists@rtty.us>
>>> Sent: Monday, December 03, 2012 11:18 AM
>>> To: "'Discussion of precise time and frequency measurement'"
>> <time-nuts@febo.com>
>>> 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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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.
>>
>>
>>
>> _______________________________________________
>> 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.
>
>
> --
> "Neither the voice of authority nor the weight of reason and argument
> are as significant as experiment, for thence comes quiet to the mind."
> De Erroribus Medicorum, R. Bacon, 13th century.
> "If you don't know what it is, don't poke it."
> Ghost in the Shell
>
>
> Dr. Don Latham AJ7LL
> Six Mile Systems LLP
> 17850 Six Mile Road
> POB 134
> Huson, MT, 59846
> VOX 406-626-4304
> www.lightningforensics.com
> www.sixmilesystems.com
>
>
>
> _______________________________________________
> 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.
BC
Bob Camp
Mon, Dec 3, 2012 8:29 PM
Hi
The key words there being "so far".
If:
- You can flood the antenna with a synthetic signal ( = come up with RF
power)
- You can synthesize synthetic sat signals ( = buy fancy signal generators
)
- 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-bounces@febo.com [mailto:time-nuts-bounces@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" djl@montana.com 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-bounces@febo.com [mailto:time-nuts-bounces@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
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" dlewis6767@austin.rr.com
wrote:
I agree, Bob.
Like the billboard on the side of the highway says: - Does Advertising
The bad guys can read this list same as the good guys.
From: "Bob Camp" lists@rtty.us
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,
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
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
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
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
the real time clock..).
One hundred microseconds per second is plenty of slip to get things
into
odd state. By the end of 24 hours, you would be off by 8.64 seconds.
Bob
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@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
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
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:
- I am an attacker. I can get remote root access to a device that
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
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
(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
in off the network. What sort of modifications to the code of that
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?
- 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
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?
- I have a long planning horizon, and access to the devices at some
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
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
and follow the instructions there.
and follow the instructions there.
--
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell
Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
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-bounces@febo.com [mailto:time-nuts-bounces@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" <djl@montana.com> 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-bounces@febo.com [mailto:time-nuts-bounces@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" <dlewis6767@austin.rr.com>
>> 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" <lists@rtty.us>
>>> Sent: Monday, December 03, 2012 11:18 AM
>>> To: "'Discussion of precise time and frequency measurement'"
>> <time-nuts@febo.com>
>>> 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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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.
>>
>>
>>
>> _______________________________________________
>> 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.
>
>
> --
> "Neither the voice of authority nor the weight of reason and argument
> are as significant as experiment, for thence comes quiet to the mind."
> De Erroribus Medicorum, R. Bacon, 13th century.
> "If you don't know what it is, don't poke it."
> Ghost in the Shell
>
>
> Dr. Don Latham AJ7LL
> Six Mile Systems LLP
> 17850 Six Mile Road
> POB 134
> Huson, MT, 59846
> VOX 406-626-4304
> www.lightningforensics.com
> www.sixmilesystems.com
>
>
>
> _______________________________________________
> 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.
EH
Erich Heine
Mon, Dec 3, 2012 8:52 PM
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: eheine@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-bounces@febo.com [mailto:time-nuts-bounces@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:
- 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?
- 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?
- 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.
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.
On Mon, Dec 3, 2012 at 11:18 AM, Bob Camp <lists@rtty.us> 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: eheine@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-bounces@febo.com [mailto:time-nuts-bounces@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 - 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.
>
>
>
> _______________________________________________
> 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.
>
JL
Jim Lux
Mon, Dec 3, 2012 11:45 PM
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"
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"
L
lists@lazygranch.com
Tue, Dec 4, 2012 12:01 AM
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 jimlux@earthlink.net
Sender: time-nuts-bounces@febo.com
Date: Mon, 03 Dec 2012 15:45:24
To: time-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
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.
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 <jimlux@earthlink.net>
Sender: time-nuts-bounces@febo.com
Date: Mon, 03 Dec 2012 15:45:24
To: <time-nuts@febo.com>
Reply-To: Discussion of precise time and frequency measurement
<time-nuts@febo.com>
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.
HM
Hal Murray
Tue, Dec 4, 2012 2:34 AM
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.
lists@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.
JL
Jim Lux
Tue, Dec 4, 2012 4:12 AM
On 12/3/12 6:34 PM, Hal Murray wrote:
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.
On 12/3/12 6:34 PM, Hal Murray wrote:
>
> lists@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.
G
gary
Tue, Dec 4, 2012 5:59 AM
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:
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.
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:
>>
>> lists@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.
>
SG
Sanjeev Gupta
Tue, Dec 4, 2012 6:10 AM
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
On Tue, Dec 4, 2012 at 1:59 PM, gary <lists@lazygranch.com> 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
JL
Jim Lux
Tue, Dec 4, 2012 1:57 PM
On 12/3/12 9:59 PM, gary wrote:
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.]
The RSA fob doesn't have a button. It just displays a 6 digit number
that changes once a minute or so. The number is generated by a pseudo
random number generator which is seeded in a way that is tied to the
serial number. The compromise last year at RSA involved someone getting
access to the serial number-seed list. (This is obviously not a "public
key" system).
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.
The problem is that how would you distinguish this from normal load
dispatch for the generator. That's how you set the power flow: you
adjust the phase of your generator to slightly leading the grid, and
power flows from generator to grid.
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.
Yes.. there are stories of big drive shafts shearing or enormous
turbomachinery ripping off the floor bolts.
It is apparently hard to move the grid.
The interconnection problem is complicated by the fact that there are
long transmission lines in the system which have all the usual
transmission line issues like reflections, etc. Your simple lab
exercise would be substantially more complicated if there were a 1000 km
long transmission line between the "grid" and "generator".
What you have in the real system is dozens of coupled oscillators, all
with their own "stiffness" coupled by a complex network of transmission
lines with propagation delays and mismatch.
On 12/3/2012 8:12 PM, Jim Lux wrote:
On 12/3/12 6:34 PM, Hal Murray wrote:
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.
On 12/3/12 9:59 PM, gary wrote:
> 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.]
The RSA fob doesn't have a button. It just displays a 6 digit number
that changes once a minute or so. The number is generated by a pseudo
random number generator which is seeded in a way that is tied to the
serial number. The compromise last year at RSA involved someone getting
access to the serial number-seed list. (This is obviously not a "public
key" system).
>
> 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.
The problem is that how would you distinguish this from normal load
dispatch for the generator. That's how you set the power flow: you
adjust the phase of your generator to slightly leading the grid, and
power flows from generator to grid.
>
> 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.
Yes.. there are stories of *big* drive shafts shearing or enormous
turbomachinery ripping off the floor bolts.
>
> It is apparently hard to move the grid.
>
The interconnection problem is complicated by the fact that there are
long transmission lines in the system which have all the usual
transmission line issues like reflections, etc. Your simple lab
exercise would be substantially more complicated if there were a 1000 km
long transmission line between the "grid" and "generator".
What you have in the real system is dozens of coupled oscillators, all
with their own "stiffness" coupled by a complex network of transmission
lines with propagation delays and mismatch.
>
>
>
> On 12/3/2012 8:12 PM, Jim Lux wrote:
>> On 12/3/12 6:34 PM, Hal Murray wrote:
>>>
>>> lists@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.
>
SM
Scott McGrath
Tue, Dec 4, 2012 10:08 PM
Some RSA fobs do have a keypad. System prompts you to enter a number on keypad and you enter the tokencode which is generated. More secure less predictable. Or you enter a pin and token generates tokencode
Sent from my iPhone
On Dec 4, 2012, at 5:57 AM, Jim Lux jimlux@earthlink.net wrote:
On 12/3/12 9:59 PM, gary wrote:
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.]
The RSA fob doesn't have a button. It just displays a 6 digit number that changes once a minute or so. The number is generated by a pseudo random number generator which is seeded in a way that is tied to the serial number. The compromise last year at RSA involved someone getting access to the serial number-seed list. (This is obviously not a "public key" system).
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.
The problem is that how would you distinguish this from normal load dispatch for the generator. That's how you set the power flow: you adjust the phase of your generator to slightly leading the grid, and power flows from generator to grid.
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.
Yes.. there are stories of big drive shafts shearing or enormous turbomachinery ripping off the floor bolts.
It is apparently hard to move the grid.
The interconnection problem is complicated by the fact that there are long transmission lines in the system which have all the usual transmission line issues like reflections, etc. Your simple lab exercise would be substantially more complicated if there were a 1000 km long transmission line between the "grid" and "generator".
What you have in the real system is dozens of coupled oscillators, all with their own "stiffness" coupled by a complex network of transmission lines with propagation delays and mismatch.
On 12/3/2012 8:12 PM, Jim Lux wrote:
On 12/3/12 6:34 PM, Hal Murray wrote:
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.
Some RSA fobs do have a keypad. System prompts you to enter a number on keypad and you enter the tokencode which is generated. More secure less predictable. Or you enter a pin and token generates tokencode
Sent from my iPhone
On Dec 4, 2012, at 5:57 AM, Jim Lux <jimlux@earthlink.net> wrote:
> On 12/3/12 9:59 PM, gary wrote:
>> 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.]
>
> The RSA fob doesn't have a button. It just displays a 6 digit number that changes once a minute or so. The number is generated by a pseudo random number generator which is seeded in a way that is tied to the serial number. The compromise last year at RSA involved someone getting access to the serial number-seed list. (This is obviously not a "public key" system).
>
>
>
>>
>> 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.
>
> The problem is that how would you distinguish this from normal load dispatch for the generator. That's how you set the power flow: you adjust the phase of your generator to slightly leading the grid, and power flows from generator to grid.
>
>
>>
>> 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.
>
>
> Yes.. there are stories of *big* drive shafts shearing or enormous turbomachinery ripping off the floor bolts.
>
>>
>> It is apparently hard to move the grid.
>
> The interconnection problem is complicated by the fact that there are long transmission lines in the system which have all the usual transmission line issues like reflections, etc. Your simple lab exercise would be substantially more complicated if there were a 1000 km long transmission line between the "grid" and "generator".
>
> What you have in the real system is dozens of coupled oscillators, all with their own "stiffness" coupled by a complex network of transmission lines with propagation delays and mismatch.
>
>
>
>>
>>
>>
>> On 12/3/2012 8:12 PM, Jim Lux wrote:
>>> On 12/3/12 6:34 PM, Hal Murray wrote:
>>>>
>>>> lists@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.
>
>
> _______________________________________________
> 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.
BH
Bill Hawkins
Wed, Dec 5, 2012 12:28 AM
Sorry about this, Tom, but there's some misinformation here.
I wasn't reading this until I saw your posting.
-----Original Message-----
From: Jim Lux
Sent: Tuesday, December 04, 2012 7:58 AM
On 12/3/12 9:59 PM, gary wrote:
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.
The problem is that how would you distinguish this from normal load
dispatch for the generator. That's how you set the power flow: you
adjust the phase of your generator to slightly leading the grid, and
power flows from generator to grid.
----- End Original Message
A. You cannot have one generator feeding the grid while being out of phase.
See any text on coupled (bussed) rotating synchronous machines.
B. There is no phase adjustment for the generator. Phase angle with respect
to the grid is determined by whether you are giving or taking power with
respect to the grid. To increase your phase lead on the grid, you apply more
steam to the turbine.
Time has nothing to do with it, except at the central dispatching office
for a generating region. If time on the grid, measured in generated cycles,
lags the number of 60 (or 50) Hz cycles since midnight (or some reference)
then the dispatcher calls for or remotely commands more power to be
generated at some stations until the lost cycles are made up. The entire
distribution network stays in synch, as it must.
Hope that clears things up.
Now, if you are talking about the huge power inverter at the junction of
a DC transmission tie line and an AC network, then yes, you can adjust the
phase angle to control power flow - but this is not controlled by a clock.
Bill Hawkins
Sorry about this, Tom, but there's some misinformation here.
I wasn't reading this until I saw your posting.
-----Original Message-----
From: Jim Lux
Sent: Tuesday, December 04, 2012 7:58 AM
On 12/3/12 9:59 PM, gary wrote:
> 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.
The problem is that how would you distinguish this from normal load
dispatch for the generator. That's how you set the power flow: you
adjust the phase of your generator to slightly leading the grid, and
power flows from generator to grid.
----- End Original Message
A. You cannot have one generator feeding the grid while being out of phase.
See any text on coupled (bussed) rotating synchronous machines.
B. There is no phase adjustment for the generator. Phase angle with respect
to the grid is determined by whether you are giving or taking power with
respect to the grid. To increase your phase lead on the grid, you apply more
steam to the turbine.
Time has nothing to do with it, except at the central dispatching office
for a generating region. If time on the grid, measured in generated cycles,
lags the number of 60 (or 50) Hz cycles since midnight (or some reference)
then the dispatcher calls for or remotely commands more power to be
generated at some stations until the lost cycles are made up. The entire
distribution network stays in synch, as it must.
Hope that clears things up.
Now, if you are talking about the huge power inverter at the junction of
a DC transmission tie line and an AC network, then yes, you can adjust the
phase angle to control power flow - but this is not controlled by a clock.
Bill Hawkins
JL
Jim Lux
Wed, Dec 5, 2012 3:22 AM
On 12/4/12 4:28 PM, Bill Hawkins wrote:
Sorry about this, Tom, but there's some misinformation here.
I wasn't reading this until I saw your posting.
-----Original Message-----
From: Jim Lux
Sent: Tuesday, December 04, 2012 7:58 AM
On 12/3/12 9:59 PM, gary wrote:
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.
The problem is that how would you distinguish this from normal load
dispatch for the generator. That's how you set the power flow: you
adjust the phase of your generator to slightly leading the grid, and
power flows from generator to grid.
----- End Original Message
A. You cannot have one generator feeding the grid while being out of phase.
See any text on coupled (bussed) rotating synchronous machines.
Yes, if the buss is infinitely stiff and infinitesimally short.
If the transmission line is 1000 km long with significant inductance and
capacitance, then the phase of a generator at one end and the phase of a
generator at the other end (or somewhere in between) will be quite
different. The AC intertie in California that runs up the central
valley, for instance, has transients (e.g. instantaneous phase
variations) that take hours to die out. One of the big advantages of DC
links is that they don't have this problem.. one end acts as a constant
current source/sink, the other as a constant voltage source/sink.(DC
links have other problems, but they're still easier than stabilizing a
1500 km long ac transmission line with sources and loads all along it)
It's fascinating to look at the phase/frequency plots during the
northeast blackout a few years ago.
There's even an IEEE Standard (1344) on timing for power lines. IEEE
1344 gives GPS timing as 200ns. that standard calls out a signal at
1pps with 1E-7 stability and 1us max variation from UTC.
Appendix B of that doc says that you need to be able to measure phase to
0.1 degree for state estimation, stability monitoring, control, and
relaying.
B. There is no phase adjustment for the generator. Phase angle with respect
to the grid is determined by whether you are giving or taking power with
respect to the grid. To increase your phase lead on the grid, you apply more
steam to the turbine.
yes.. I was sloppy.. but the point is that the phase of the power coming
out of the generator slightly leads that of the "sink" (e.g. current
flows FROM generator to grid).
Time has nothing to do with it, except at the central dispatching office
for a generating region. If time on the grid, measured in generated cycles,
lags the number of 60 (or 50) Hz cycles since midnight (or some reference)
then the dispatcher calls for or remotely commands more power to be
generated at some stations until the lost cycles are made up. The entire
distribution network stays in synch, as it must.
The way they measure relative phase (and frequency) is by comparison
with a good clock. There's a nifty website out there that shows the
instantaneous and integrated phase difference between various places on
the pacific coast, so you can see power flow changing.
Hope that clears things up.
Now, if you are talking about the huge power inverter at the junction of
a DC transmission tie line and an AC network, then yes, you can adjust the
phase angle to control power flow - but this is not controlled by a clock.
Bill Hawkins
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.
On 12/4/12 4:28 PM, Bill Hawkins wrote:
> Sorry about this, Tom, but there's some misinformation here.
> I wasn't reading this until I saw your posting.
>
> -----Original Message-----
> From: Jim Lux
> Sent: Tuesday, December 04, 2012 7:58 AM
>
> On 12/3/12 9:59 PM, gary wrote:
>> 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.
>
> The problem is that how would you distinguish this from normal load
> dispatch for the generator. That's how you set the power flow: you
> adjust the phase of your generator to slightly leading the grid, and
> power flows from generator to grid.
>
> ----- End Original Message
>
> A. You cannot have one generator feeding the grid while being out of phase.
> See any text on coupled (bussed) rotating synchronous machines.
Yes, if the buss is infinitely stiff and infinitesimally short.
If the transmission line is 1000 km long with significant inductance and
capacitance, then the phase of a generator at one end and the phase of a
generator at the other end (or somewhere in between) will be quite
different. The AC intertie in California that runs up the central
valley, for instance, has transients (e.g. instantaneous phase
variations) that take hours to die out. One of the big advantages of DC
links is that they don't have this problem.. one end acts as a constant
current source/sink, the other as a constant voltage source/sink.(DC
links have other problems, but they're still easier than stabilizing a
1500 km long ac transmission line with sources and loads all along it)
It's fascinating to look at the phase/frequency plots during the
northeast blackout a few years ago.
There's even an IEEE Standard (1344) on timing for power lines. IEEE
1344 gives GPS timing as 200ns. that standard calls out a signal at
1pps with 1E-7 stability and 1us max variation from UTC.
Appendix B of that doc says that you need to be able to measure phase to
0.1 degree for state estimation, stability monitoring, control, and
relaying.
>
> B. There is no phase adjustment for the generator. Phase angle with respect
> to the grid is determined by whether you are giving or taking power with
> respect to the grid. To increase your phase lead on the grid, you apply more
> steam to the turbine.
yes.. I was sloppy.. but the point is that the phase of the power coming
out of the generator slightly leads that of the "sink" (e.g. current
flows FROM generator to grid).
>
> Time has nothing to do with it, except at the central dispatching office
> for a generating region. If time on the grid, measured in generated cycles,
> lags the number of 60 (or 50) Hz cycles since midnight (or some reference)
> then the dispatcher calls for or remotely commands more power to be
> generated at some stations until the lost cycles are made up. The entire
> distribution network stays in synch, as it must.
The way they measure relative phase (and frequency) is by comparison
with a good clock. There's a nifty website out there that shows the
instantaneous and integrated phase difference between various places on
the pacific coast, so you can see power flow changing.
>
> Hope that clears things up.
>
> Now, if you are talking about the huge power inverter at the junction of
> a DC transmission tie line and an AC network, then yes, you can adjust the
> phase angle to control power flow - but this is not controlled by a clock.
>
> Bill Hawkins
>
>
> _______________________________________________
> 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.
>
