DHCP already has support for providing an NTP server IP; there has been at least one proposal[1] to also provide a DHCP option specifying the "rough current time", so that devices have at least _something_ to start with. As for trust, you're already going to be trusting DHCP to give you an IP address, you could also trust it for this (with some safeguard in place to catch known-wrong values).<p>This kindof reinforces how having an 'IoT Gateway' would be a good idea: The gateway can provide DHCP, and rough time, and (S)NTP, and DNS, and can also act as a proxy to the outside.<p>[1]: <a href="http://www.potaroo.net/ietf/idref/draft-ogud-dhc-udp-time-option/" rel="nofollow">http://www.potaroo.net/ietf/idref/draft-ogud-dhc-udp-time-op...</a>
Articles that go around in circles while avoiding reflection or synthesis are infuriating. Of course relying on the PKI isn't going to magically solve every problem. But the article wasn't titled "Why you can't trust the PKI", because we're all bored of reading about that.<p>At a certain point, you <i>must</i> choose some <i>immutable</i> trust root. If your kink is to use public CAs (fuck me harder, (go)daddy), it implies attacks. If you chose to setup your own private signing key, it implies attacks. If you choose longest sha256 chain ("blockchain"), it implies attacks. If you simply stop trying to retain absolute control over devices after they're owned by someone else, it implies attacks.<p>You can hardcode further constraints as mitigations, but the fundamental drawbacks remain. If you want direct synthesis from the immediate complaint, keep a bit of a state to ensure that the date only ever moves monotonically forward. However you'll still be open to an attack if the device is off while a certificate is compromised.
This is a genuine problem across a variety of platforms, not just IoT. There really is no great way to "solve" for trust when one party might have extremely stale information. Awareness of this problem is surprisingly poor.<p>> In the next blog post of this series we want to introduce a new secure network time protocol based on blockchain technology and show how even the smallest devices can establish completely secure connections.<p>This is a pretty disappointing way to end the article. Most "solutions" end up being some form of obfuscation, I'd guess this is too.
There is only a catch-22 if we need _that time source_ to verify its time.<p>That's not how things work, though: we have hundreds available, so there is no catch-22 whatsoever: we check multiple sources and go with the majority vote, then flag an error for any outlier(s).
If we can't get precise time securely and do not have real-time clock, it does not mean, there are no options left.<p>For instance, device may be booted for the first time in secure controlled environment and synchronize time fro trusted source.<p>Then, every N seconds (like 60 to 3600), device will write current time to local file. Most devices have some kind of writable local storage.<p>Any next synchronization will not be able to return time before already experienced moment. Certificate expiration will actually work, with a bit higher tolerance of a few hours.
Adam Langley's Roughtime protocol[1] largely solves some (but not all types) of time malfeasance, and a variant of it is already an IETF draft specification[2]. There is also NTS, which is secure NTP and provides some protections, but not nearly as many.<p>[1]: <a href="https://roughtime.googlesource.com/roughtime/" rel="nofollow">https://roughtime.googlesource.com/roughtime/</a><p>[2]: <a href="https://tools.ietf.org/html/draft-roughtime-aanchal-01" rel="nofollow">https://tools.ietf.org/html/draft-roughtime-aanchal-01</a>
An (interesting, but impractical) solution to this problem would be to use astronomy to deduce the current date first, which should be good enough to validate the certificate.<p>See this QA on Astronomy StackExchange: <a href="https://astronomy.stackexchange.com/questions/12886/get-date-and-time-by-position-of-the-sun-and-the-observer-position" rel="nofollow">https://astronomy.stackexchange.com/questions/12886/get-date...</a>
One could pin a cert, hope the device is powered on in the validity period to update it? Obviously a bad idea for other reasons but maybe it's the best worst choice.
Assuming something in the trusted side of the network chain has a persistent clock or verified time then this issue could be avoided. For things that connect directly to untrusted networks e.g. public cellular internet the only solution I can see is using devices with a persistent clock themselves.
IETF working group - <a href="https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time...</a>
I'm probably the only one who thinks it's really stupid to connect things like refrigerators and washing machines to the internet, but I'm going to say it anyway.