Fredrik Lindeberg
Fredrik Lindeberg, 
Roughtime: Securing time for IoT devices

Roughtime: Securing time for IoT devices

Marcus Dansarie, Independent Consultant at Netnod, discussed Roughtime at the Netnod Meeting 2025. His presentation covered the Roughtime draft protocol for securely providing time to devices—especially in IoT scenarios—without needing an accurate starting time. The presentation also covered how Roughtime can give cryptographic proof of server malfeasance and act as a complement to existing time protocols like NTP and NTS.

This is part of a series focusing on the presentations from the Netnod Meeting 2025. Each blogpost aims to summarise the key points from the presentation and provides links for readers who want to know more.
 

The importance of correct time

Correct time is important for almost all security critical applications.This includes, but is not limited to, DNSSEC, TLS (and HTTPS, SMTPS, IMAPS, and all other protocols depending on TLS), authentication tokens, 2FA, logging, and so forth.

Some applications depend on accurate time at the level of seconds (authentication), others on hours (DNSSEC). 

If an application has incorrect time, the application might be tricked into accepting revoked certificates and tokens, or correct certificates and tokens might cease to function. 

Another issue is getting the correct time. The first time an electronic device is booted up it probably does not know the time. And over time, a device might lose time. 

Getting time over the network

One way to refresh your time or to get the time is to use Network Time Protocol (NTP) or Network Time Security (NTS), the latter adding scalable authentication to the former. However, both NTP and NTS have significant cons; NTP since it is commonly used without authentication and vulnerable to attack, and NTS since it depends on having good time to start with due to its dependence on TLS.

A possible solution to getting the time over network is the draft protocol Roughtime which has been designed from the ground up to provide authentication without the need for a good starting point of time. Roughtime is not per se intended to replace NTP or NTS, rather to complement them. 

Roughtime is based on two central concepts:

  • Long-term public keys, that is keys which stay the same for decades
  • Clients should ask multiple servers for time to avoid singular misbehaving servers

Illustration of the Roughtime process

Figure 1: Illustration of the Roughtime process

A unique feature of Roughtime is the possibility of a client to cryptographically prove server malfeasance. This is possible because nonces / hashed responses are used in requests which can be used to prove that queries were received in a certain order, and also what the answer was.

Roughtime is focused on providing a secure by default time transfer protocol with fairly low CPU usage and small memory footprint. The protocol can prove malfeasance and timestamp arbitrary data. Roughtime provides single-second resolution. 

Further information

In the next few months, Roughtime will hopefully become an experimental RFC. Once this happens, implementations will need to be updated, and hopefully an ecosystem of globally distributed Roughtime servers will start to grow.

If you want to try Roughtime, have a look at some of these implementations:

Most come with a list of servers (ecosystem.json). You can also use roughtime.se. 

You can watch the Roughtime presentation from the Netnod Meeting 2025 here and see the slides here.

 

Related blog articles

Show all blog articles