
You Can't Trust Network Time - dominicl
https://diode.io/burning-platform-pki/2019/04/26/why-we-cant-trust-network-time.html
======
CaliforniaKarl
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).

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...](http://www.potaroo.net/ietf/idref/draft-ogud-dhc-udp-time-option/)

~~~
josteink
> 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?

~~~
gumby
I doubt most routers provide DHCP. Maybe consumer ones.

~~~
detaro
What's the point of this nitpick?

Networks that configure everything statically are fairly rare, and do so
intentionally. If they don't, they have a DHCP server somewhere already, and
if they aren't consumer-level networks they sure as hell don't want some
random "IoT gateway" box providing DHCP. So it's clear what "router" means in
this context.

~~~
gumby
I have a separate dhcp server so if the router has issues machines can still
attach to the network and talk to local services.

------
mindslight
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.

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.

------
xyzzy_plugh
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.

> 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
A 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.

------
TheRealPomax
There 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
If 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
Sure, 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.

------
adontz
If 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.

------
becauseiam
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.

[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)

------
k_sze
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.

See this QA on Astronomy StackExchange:
[https://astronomy.stackexchange.com/questions/12886/get-
date...](https://astronomy.stackexchange.com/questions/12886/get-date-and-
time-by-position-of-the-sun-and-the-observer-position)

------
exabrial
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.

------
yjftsjthsd-h
Maybe dumb, but... Why not just make ntpd actually check certificate
revocation? Easier than fixing everything that uses HTTPS, and seems to fix
it?

~~~
wmf
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.

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.

~~~
NullPrefix
>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.

~~~
yardstick
OpenWrt can use the last modified timestamp of a file, eg the most recently
updated log file. It’s a decent middle ground.

------
zamadatix
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.

------
imglorp
IETF working group - [https://datatracker.ietf.org/doc/draft-ietf-ntp-network-
time...](https://datatracker.ietf.org/doc/draft-ietf-ntp-network-time-
security/)

------
noja
So ignore the time on the cert? Isn't that better than having no cert?

~~~
kevin_nisbet
The 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).

------
sverige
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.

~~~
myself248
And 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.

~~~
bdamm
Mine has an LED that indicates “clean” and slaves from the internal door
switch. Handy source.

~~~
rzzzt
This could be eg. an SNMP metric/trap, along with other sensors in the
machine, then parent could add the "smartness" via their own software.

