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.
[1]: http://www.potaroo.net/ietf/idref/draft-ogud-dhc-udp-time-op...
Aka a router. Am I missing something?
Unfortunately it's technically challenging to create a configuration to use it in a meaningful way, especially when the system reboots.
Really what you need is a process to bring up the GPS, wait until the time is up and reliable, then set the hardware clock and launch NTP "correctly" (without falsetickers and all the other ntp convergence nonsense)
The only viable option for us is about 3 (or more) rackmount NTP appliances from a well known vendor which have the GPS already integrated, support for multiple time source modules and power supplies, and have integrated software to drive the whole thing. This means we need to get GPS antennas installed on the roof of the datacenter and fiber run from there to our racks.
Our remote sites (connected by 4G and VSAT) also have GPS units, but they are connected via RS-232 serial (not USB) and suffer from some of the synchronization issues you describe. They fallback to the time servers in the datacenters in the event that the local GPS time source is rejected.
I wouldn't mind if my washing machine could ding my phone when there's a load of damp clothes in there that I need to handle before they grow mold. That's cool, I'm forgetful, and I waste a lot of water being that forgetful. But it shouldn't need to talk to the internet to do that.
The problem is not smart appliances, per se, it's the centralized and vulnerable way those smarts are being implemented. Because it's in the manufacturer's interest to compromise my own security and autonomy.
Which is why I don't own any, and I'm sitting here working on my own washing machine door transmitter instead.
Ding ding ding. Most things could be easily implemented without adding external dependencies or impacting privacy but there's no coin in it.
But usually 0 out of 3 of those are true.
The devices come from companies that specialize in hardware, so the software is usually an afterthought.
They don't prioritize keeping it secure because they know customers are more interested in features like whether the refrigerator's shelf configuration or the washing machine's capacity.
And they don't commit to supporting it for the lifetime of the product because once they have your money, they have little incentive.
As a matter of fact, I run NTP at home and get the time from an inexpensive USB GPS dongle. (I actually use more than one)
Unfortunately I believe you need 4 to do it right with the way NTP seems to work
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 you have trouble imagining a user taking their wifi lightbulb to a coffee shop, imagine instead you're a device vendor and a customer is trying to MITM their own device to embarrass you in a Defcon presentation...
2. The device is being MITMed so it receives a time of, say 2010 with a certificate that is also valid for 2010 even though that certificate is long expired in reality. The device has no way to know otherwise.
I don't know the point of this attack though.
Defaulting to date of manufacture instead of unix timestamp 0 would get you closer, although it's still not a solution.
You could also periodically store time in a non volatile memory, to be loaded on boot.
> 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.
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.
When using NTP and having stolen a certificate in the IOT devices trust store for example.com. I spoof the time and then I can spoof example.com because the devices clock is now in the validity time for the stolen certificate.
When using server time over TLS and having stolen a certificate, the device on cold boot (Or all the time depending on how well written it's implemented) will connect to the server ignoring the validity time, and again get it's clock set to a time that matches the certificate.
Either of these methods require compromising the private key for the cert. Basically the weakness is using time to limit the window for a compromised cert is a lot harder on IOT devices which routinely don't maintain their clocks.
Now, if the TLS based time service was running under a different cert, it might change the surface area a bit. Since the cert for the TLS based time service would also need to be breached, along with the example.com certificate (2 certs in theory should be harder to breach, but it depends on the org and how they leaked the secret in the first place).
This also depends on the IOT device manufacturer not signing a certificate for 25 years that will basically never expire regardless of the time (which I've seen).
At a certain point, you must choose some immutable 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.
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.
For instance, device may be booted for the first time in secure controlled environment and synchronize time fro trusted source.
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.
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.
See this QA on Astronomy StackExchange: https://astronomy.stackexchange.com/questions/12886/get-date...
