Assuming devices like this get their IP via DHCP, there is a solution that does not involve hard-coding IPs into software.
DHCP option 42 (defined in RFC 2132) can be used to specify multiple NTP server IPv4 addresses.
(There’s also DHCP option 4, but that’s used to specify the IP for the older RFC 868 time protocol.)
DHCPv6 has option 31 for SNTP (via deprecated RFC 4075), and option 56 for NTP (via RFC 5908).
So, that would probably be the best option: Get an NTP address from DHCP or DHCPv6, use that to set your clock, bring up DNS over TLS/HTTPS, re-configure NTP with your preferred source, re-sync your clock, and then continue booting!
I've got a small Raspberry Pi clone set up with a GSP module running chronyd[2], advertised via DHCP as mentioned by GP. Didn't take much time or effort.
I also added a RTC module so it could hold reasonable time during power-loss but I haven't had a chance to verify that it works as expected.
[1]: https://www.aliexpress.com/item/1005001623104119.html The 7M and M8N are both much better than the 6M, regardless get a module with PPS output pin, not all have it. And grab an active antenna, you'll probably need it.
I did something similar but went a bit more overboard because I could partially write it off as an experiment for work. I found this carrier board for the CM4:
which is pretty nice because it has an onboard RTC and battery backup. I then added on a timing specific GPS module that was made to fit onto the GPIO pins (https://www.tindie.com/products/nsayer/gps-timing-module-bre...). The CM4 is interesting because it supports hardware timestamping on the ethernet so it can actually run PTP for ultra-precise synchronization. Also added one of those SPI 8 digit seven segment displays and wrote a crappy little program to update the time as fast as possible for some bling. It sucks the CM4 ended up being the biggest cost of the project since I ended up paying ~80 bucks for it. Still far cheaper than the cost of a "real" PTP host.
Sorry, yeah I mean Pi-like SBC, ie with GPIO. In my case a NanoPi NEO-LTS[1], mainly because I had one available and I didn't need much hardware just to run the NTP (it's all it does).
It runs Armbian[2] and has been sitting there doing its thing for a few years now.
All you need is a GPIO for PPS, but it's nice to have the UART so it can parse the time and such.
edit: since it's slightly different on Armbian from a Raspberry Pi, you need to enable the pps-gpio overlay similarly[3], but the pin parameter is different[4], for the H3 in the NanoPi NEO for example see here[5].
Potentially this has a hole: if a wrong time is set initially, then wrong certificates may be trusted, so spoofed TLS sessions with compromised (and expired) certificates would work, potentially giving a way to install something malicious. It requires some massive spoofing on the outside though.
If the initial NTP addresses are within a datacenter LAN (say, 10.x.x.x, etc), they are likely harder to spoof. Should be fine their case (servers).
Yeah I guess in general if the security of TLS depends on correct timekeeping (eg a compromised key enables an attacker to use an old cert), then in theory we should secure the time sync protocol. The NIST servers page [1] describes an authenticated+encrypted NTP for VIPs, but I don't know a solution for the layperson.
For TLS, you need a roughly correct time; being many minutes off is usually acceptable. No need for GPS clocks and other such stuff.
Ideally your machine should have a functioning battety-backed RTC. The vast majority of larger machines do.
In a data center, DHCP or well-known local addresses should offer hard-to-spoof poiners to local NTP servers for bootstrapping.
I don't see a large problem here; a reasonable startup sequence that makes sure a correct time is set before attempting TLS connections should just work. DNS requiring TLS and thus a correct system time is slightly novel, so approaches ignoring it expectedly fail.
What do you do with embedded devices where the RTC battery has died? Replace the battery but you have no way to set the clock and the device won't connect to anything anymore because its clock is off, so just throw it away then? Doesn't sound environmentally friendly... And yes CR2032 batteries can last a long time but they can also fail, just a a month ago I had to replace one that was only a year old.
Attach a com port, set the date correctly, since you came to replace the battery anyway :-/
Frankly, there is a balancing act between the desire for a device to work unattended for the longest time, and security implications of running an outdated or degraded device. Now that the RTC becomes more important, equip it with better batteries :(
Comments
Assuming devices like this get their IP via DHCP, there is a solution that does not involve hard-coding IPs into software.
DHCP option 42 (defined in RFC 2132) can be used to specify multiple NTP server IPv4 addresses.
(There’s also DHCP option 4, but that’s used to specify the IP for the older RFC 868 time protocol.)
DHCPv6 has option 31 for SNTP (via deprecated RFC 4075), and option 56 for NTP (via RFC 5908).
So, that would probably be the best option: Get an NTP address from DHCP or DHCPv6, use that to set your clock, bring up DNS over TLS/HTTPS, re-configure NTP with your preferred source, re-sync your clock, and then continue booting!
I've got a small Raspberry Pi clone set up with a GSP module running chronyd[2], advertised via DHCP as mentioned by GP. Didn't take much time or effort.
I also added a RTC module so it could hold reasonable time during power-loss but I haven't had a chance to verify that it works as expected.
[1]: https://www.aliexpress.com/item/1005001623104119.html The 7M and M8N are both much better than the 6M, regardless get a module with PPS output pin, not all have it. And grab an active antenna, you'll probably need it.
[2]: https://austinsnerdythings.com/2021/04/19/microsecond-accura...
I did something similar but went a bit more overboard because I could partially write it off as an experiment for work. I found this carrier board for the CM4:
https://www.ebay.com/itm/384876455621
which is pretty nice because it has an onboard RTC and battery backup. I then added on a timing specific GPS module that was made to fit onto the GPIO pins (https://www.tindie.com/products/nsayer/gps-timing-module-bre...). The CM4 is interesting because it supports hardware timestamping on the ethernet so it can actually run PTP for ultra-precise synchronization. Also added one of those SPI 8 digit seven segment displays and wrote a crappy little program to update the time as fast as possible for some bling. It sucks the CM4 ended up being the biggest cost of the project since I ended up paying ~80 bucks for it. Still far cheaper than the cost of a "real" PTP host.
Cool! I've been reading up on it but hadn't realized the CM4 supported that. Will need to look into that a bit deeper, thanks!
When you say Raspberry Pi clone, is it a real clone? Or is it just another single board computer?
Sorry, yeah I mean Pi-like SBC, ie with GPIO. In my case a NanoPi NEO-LTS[1], mainly because I had one available and I didn't need much hardware just to run the NTP (it's all it does).
It runs Armbian[2] and has been sitting there doing its thing for a few years now.
All you need is a GPIO for PPS, but it's nice to have the UART so it can parse the time and such.
edit: since it's slightly different on Armbian from a Raspberry Pi, you need to enable the pps-gpio overlay similarly[3], but the pin parameter is different[4], for the H3 in the NanoPi NEO for example see here[5].
[1]: https://www.friendlyelec.com/index.php?route=product/product...
[2]: https://www.armbian.com/nanopi-neo/
[3]: https://forum.armbian.com/topic/9901-pps-gpio-no-longer-defa...
[4]: https://docs.armbian.com/User-Guide_Armbian_overlays/#overla...
[5]: https://github.com/armbian/sunxi-DT-overlays/blob/d925cfbb0c...
Potentially this has a hole: if a wrong time is set initially, then wrong certificates may be trusted, so spoofed TLS sessions with compromised (and expired) certificates would work, potentially giving a way to install something malicious. It requires some massive spoofing on the outside though.
If the initial NTP addresses are within a datacenter LAN (say, 10.x.x.x, etc), they are likely harder to spoof. Should be fine their case (servers).
Yeah I guess in general if the security of TLS depends on correct timekeeping (eg a compromised key enables an attacker to use an old cert), then in theory we should secure the time sync protocol. The NIST servers page [1] describes an authenticated+encrypted NTP for VIPs, but I don't know a solution for the layperson.
[1] https://tf.nist.gov/tf-cgi/servers.cgi
For TLS, you need a roughly correct time; being many minutes off is usually acceptable. No need for GPS clocks and other such stuff.
Ideally your machine should have a functioning battety-backed RTC. The vast majority of larger machines do.
In a data center, DHCP or well-known local addresses should offer hard-to-spoof poiners to local NTP servers for bootstrapping.
I don't see a large problem here; a reasonable startup sequence that makes sure a correct time is set before attempting TLS connections should just work. DNS requiring TLS and thus a correct system time is slightly novel, so approaches ignoring it expectedly fail.
What do you do with embedded devices where the RTC battery has died? Replace the battery but you have no way to set the clock and the device won't connect to anything anymore because its clock is off, so just throw it away then? Doesn't sound environmentally friendly... And yes CR2032 batteries can last a long time but they can also fail, just a a month ago I had to replace one that was only a year old.
Attach a com port, set the date correctly, since you came to replace the battery anyway :-/
Frankly, there is a balancing act between the desire for a device to work unattended for the longest time, and security implications of running an outdated or degraded device. Now that the RTC becomes more important, equip it with better batteries :(
You can't expect everyone to do that. Some devices don't have an UART hell some even don't have the pins soldered on to them.
... and then you have consumers, who don't know what UART, serial port or whatever might be, but just want their "smart" appliance to work.
If you control dhcp, then you could also just include time info in the response, for example option 152.
Do clients support it ? I never have seen option to take time from DHCP request in client settings
Sounds pretty good in theory, but this is for a router and somehow I doubt many ISPs are doing what you describe.
They’d have to acquire old certificates for every domain you’d like to visit using an encrypted connection. Not very likely.