Roughtime is a draft protocol aimed at providing a secure way for IoT devices to obtain time. In this Q&A from Netnod, Marcus Dansarie, Technical Consultant at Netnod and co-author of the IETF draft on Roughtime, answers questions on why secure time is essential, the challenges for IoT devices, and how the protocol could be the solution to a widespread problem.
Many important security protocols depend on secure and accurate time to work correctly. But with the resource constraints in many IoT devices, there is currently no way to guarantee these devices can receive time from an accurate and trusted source. This leaves billions of devices without a secure method of getting time and vulnerable to attack. Roughtime is a protocol that is being developed to fix this problem.
1. Why is accurate and secure time so important?
Time synchronisation is essential for security. Critical security processes such as encryption, authentication, and data integrity checks rely on accurate and secure time. For instance, Transport Layer Security (TLS), which gives us secure communication across the Internet, uses certificates that are only valid within specific timeframes. Incorrect time can lead to certificate verification failures leaving devices unable to establish secure connections.
Inaccurate or tampered time can also lead to cyberattacks. These include replay attacks, where an attacker reuses previously valid certificates, and man-in-the-middle attacks, where an attacker manipulates time to intercept and alter communications. The vulnerability of the Network Time Protocol (NTP) to these types of threats led to the development of Network Time Security (NTS) which secures time using cryptographic protection. There are also commercial time services delivered over dedicated fibre that ensure secure and high-precision time synchronisation.
2. What are the main issues stopping IoT devices from getting accurate and secure time?
The primary challenge lies in the resource constraints of many IoT devices. These devices often have limited processing power and memory making it impossible to use robust security protocols like NTS. The resources required to handle the public-key cryptography used in NTS are beyond the capability of many IoT devices.
The other problem is a bootstrapping issue. When an IoT device is powered on for the first time it has no idea of the time. To set up NTS, the device needs TLS which doesn’t work without the time being correct. An IoT device could get time from NTP but then you are back to the security issues with NTP we discussed in (1).
3. How does Roughtime solve the problem?
Roughtime focuses on providing a secure, lightweight, and resource-efficient way for IoT devices to obtain time. Unlike NTP, Roughtime always requires cryptographic verification, ensuring that the time information received by a device can be authenticated. Although NTS provides a mechanism for authenticated NTP, it is based on TLS. This can be hard to implement on small IoT platforms, especially when considering the requirement to keep an up-to-date root certificate database.
Roughtime uses digital signatures to ensure the authenticity of time data. When a device requests the current time, the Roughtime server responds with a signed timestamp, along with a cryptographic proof that can easily be verified by the client. Roughtime signatures are rooted in long-term keys instead of a certificate hierarchy making them significantly easier to verify. This approach allows even resource-constrained devices to validate the time they receive without the need to implement the entire TLS protocol.
Additionally, Roughtime includes mechanisms to detect and reject responses that are outside an expected range protecting against attempts to send falsified time data. The protocol is also designed to be tolerant of small inaccuracies making it suitable for environments where precise time synchronisation is not critical but where security is vital.
4. What are the next steps for Roughtime?
Roughtime is still in the development phase, with ongoing work to finalise the IETF draft and refine the protocol based on feedback from the community. The next steps involve updating client implementations to reflect the latest IETF draft, expanding the deployment of Roughtime servers, and conducting further testing in real-world IoT environments.
5. More information
At the RIPE NCC Open House focusing on projects funded by the RIPE Community Fund, Marcus Dansarie gave an update on work to develop the IETF Roughtime draft. You can see the slides here.
You can also see Christer Weinigel’s Roughtime presentation from RIPE 87. See the presentation here.
For more on Netnod’s work developing world-leading time services, see here.
Comments 0