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 -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
