7 ms·
You Can't Trust Network Time
- yjftsjthsd-h 7y agoMaybe dumb, but... Why not just make ntpd actually check certificate revocation? Easier than fixing everything that uses HTTPS, and seems to fix it?
- deleted 7y ago[deleted]
- wmf 7y ago1. The device doesn't have a battery, so when it boots it thinks the time is Jan 1, 1970. X.509 wasn't even invented at that point so there are no valid certificates for that date. 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.
- yjftsjthsd-h 7y agoI understand that we can't validate by time. But we can go fetch revocation lists.
- NullPrefix 7y ago>1. The device doesn't have a battery, so when it boots it thinks the time is Jan 1, 1970. X.509 wasn't even invented at that point so there are no valid certificates for that date. 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.
- xyzzy_plugh 7y agoYes, there's lots you can do to mitigate the risk but nothing perfect. Which, realistically speaking, is quite fine.
- yardstick 7y agoOpenWrt can use the last modified timestamp of a file, eg the most recently updated log file. It’s a decent middle ground.
- michaelt 7y agoRight, but Let's Encrypt certificates are only valid for 90 days. And there's loads of electronics in the world that's been powered off for more than 90 days :)
- toast0 7y agoAs mentioned downstream, a cached revocation list could be served. Additionally, certs that expire are not commonly revoked, and revoked certificates may be removed from revocation lists after they expire.
- sverige 7y agoI'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.
- xyzzy_plugh 7y agoYou're not, but that's only a small piece of it. IP cameras, smart speakers, tablets, e-readers, smart watches, etc., all have this problem in some form or the other.
- myself248 7y agoAnd it's even stupider to give the user zero local tools to interact with them short of letting them loose on the big bad internet. 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.
- noja 7y agoSo ignore the time on the cert? Isn't that better than having no cert?
- kevin_nisbet 7y agoThe reason I think they're effectively equivalent is say I have an IOT device that it's command and control is on example.com. 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).
- CaliforniaKarl 7y agoDHCP 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). 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-option/ http://www.potaroo.net/ietf/idref/draft-ogud-dhc-udp-time-op...
- tinus_hn 7y agoDo you trust your local McDonalds with that kind of access?
- F_r_k 7y agoIf you have no time information (i.e. no rtc), then yes
- josteink 7y ago> 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 Aka a router. Am I missing something?
- mschuster91 7y agoYes, as routers generally only speak Ethernet and WiFi while IoT devices speak Zigbee, BT/LE, Powerline, 433 MHz custom protocols, a bunch of low power WAN protocols and for the more professional/industry settings CANbus, Profibus and more.
- josteink 7y agoAFAIK Powerline is Ethernet, so that’s covered. Zigbee, BT/LE, 433Mhz and friends don’t do IP, so they won’t need DHCP and DNS. So again... What am I missing?
- imglorp 7y agoIETF working group - https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-security/ https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time...
- xyzzy_plugh 7y agoThis 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. > 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.
- bdamm 7y agoA verifiable way to put bounds on time is a very useful thing. If you know the time within an hour or even within a day can be a big help. There are cases where I’ve used firmware build time as a lower bound for current time.
- deleted 7y ago[deleted]
- TheRealPomax 7y agoThere is only a catch-22 if we need _that time source_ to verify its time. 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).
- michaelt 7y agoIf your wifi connection is MITMed, your adversary could MITM all the connections, even if you make hundreds. 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...
- TheRealPomax 7y agoSure, but now you've turned it from "You can't trust network time" into "you can't trust your wifi" and while 100% correct: now you're commenting on a different article altogether.
- Xylakant 7y agoHow do you know that it’s not the majority of your sources that has been mitm’ed?
- Kenji 7y agoI initially read: "Why you can't trust New York Times." Might've been an interesting article too.
- mindslight 7y agoArticles 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. 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.
- exabrial 7y agoOne 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.
- becauseiam 7y agoAdam 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. [1]: https://roughtime.googlesource.com/roughtime/ https://roughtime.googlesource.com/roughtime/ [2]: https://tools.ietf.org/html/draft-roughtime-aanchal-01 https://tools.ietf.org/html/draft-roughtime-aanchal-01
- adontz 7y agoIf we can't get precise time securely and do not have real-time clock, it does not mean, there are no options left. 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.
- k_sze 7y agoAn (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. See this QA on Astronomy StackExchange: https://astronomy.stackexchange.com/questions/12886/get-date-and-time-by-position-of-the-sun-and-the-observer-position https://astronomy.stackexchange.com/questions/12886/get-date...
- zamadatix 7y agoAssuming 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.