NTP & NTS - Why Time Without Trust is Worthless in Distributed Systems

Time is More Than Just a Timestamp

«Time is what you read off a clock.» Albert Einstein

As Albert Einstein put it, this is often how it is handled in embedded systems. Time is taken as a given: an NTP server, a timestamp - done. In distributed and safety-critical systems, however, time has many functions and serves for:

• Log & event correlation
• Validation of certificate validity
• Making security decisions
• As well as diagnosis and troubleshooting

Is time actually to be considered a given, and does it correspond to what was read off the clock? If not, this has far-reaching consequences for operations and security. Because without trustworthy time, even correctly encrypted communication becomes vulnerable. Time is therefore not just an operating parameter, but a security-relevant anchor of trust.

NTP – Proven but Not Secure

The Network Time Protocol (NTP) has been the standard for time synchronization for decades.

It is efficient, lightweight, and widely used. However, it was not designed for open and distributed networks.

Classic NTP offers:

• no cryptographic authentication
• no protection against manipulation
• no guarantee regarding the origin of the time information

While earlier extensions like Autokey attempted to add protection, they are now considered cryptographically insecure and obsolete.

In isolated networks, this may be sufficient, but in modern, distributed systems, it no longer is.

Fig. 1 Structure of Basic NTP Frame

Why False Time is a Security Problem

Manipulated or unreliable time directly affects security mechanisms:

• Certificates appear to be expired or still valid
• Logs lose their chronological order
• Replay attacks are facilitated
• Analysis and troubleshooting become more difficult

Time determines whether security mechanisms succeed or fail. It is therefore a fundamental component of any secure design, as required by the Cyber Resilience Act (CRA).

NTS – Time Gets an Identity

Network Time Security (NTS) extends NTP by exactly what was missing until now:

• Authenticity of the time source
• Integrity of the time information
• Protection against manipulation and replay attacks

NTS cryptographically binds the time source to a unique identity and uses established security mechanisms such as TLS and X.509 certificates. This makes time verifiable and trustworthy.

How NTS Works Technically – Security in Two Phases

NTS deliberately separates trust establishment from time synchronization.
This division is the key to combining security and efficiency.

Fig. 2 Two-Phase Model of NTS

Phase 1: Trust Establishment via TLS

In the first phase, the NTS client establishes a TLS-secured connection to the NTS server (typically via TCP).

The following happens:

• The client checks the X.509 certificate of the time server
• The chain of trust, validity period, and server identity are validated
• Cryptographic keys and so-called NTS cookies are negotiated

These cookies are not session cookies, but cryptographically protected state containers that are generated and checked exclusively by the server. The server remains stateless because all security-relevant information is contained within the cookies.

Phase 2: Secured Time Synchronization via UDP

After a successful TLS handshake, NTS switches to the second phase.

The actual time synchronization now takes place again via classic NTP packets on UDP, but extended by the previously received NTS cookies.

This means:

• NTP requests contain cryptographically protected cookies
• Responses can be checked for integrity and authenticity
• Manipulations or replay attacks are reliably detected

UDP remains deliberately in use:

• low latency
• high scalability
• full compatibility with existing NTP infrastructure

Thus, NTP remains:

• lightweight
• performant
• network-friendly

and is simultaneously secured even over insecure transport media like UDP.

Fig. 3 Secured NTP Frame with NTS Extension

It is important to understand that while NTS guarantees the authenticity of the time source and the immutability of the transmitted time, it does not guarantee that the time source itself is correctly configured or physically exact. NTS is a protection against manipulation, but not against incorrect reference time.

Why This Two-Phase Model is Crucial

The design of NTS combines two seemingly contradictory requirements:

• strong security through TLS and certificates
• high efficiency through stateless UDP communication

Through the clear separation:

• TLS is only used where necessary
• time synchronization remains scalable
• many endpoints can be synchronized securely

Time is thus not only distributed but provided in a demonstrably trustworthy manner.

Why NTS Doesn't Work Without PKI

At this point, the circle closes back to the previous blog post (Link PKI & CMP).

NTS requires:

• trustworthy certificates
• clean trust anchors
• valid lifespans
• functioning revocation

Without PKI, NTS is technically usable but not trustworthy.

Securing time is based on the same mechanisms as TLS or automated certificate management:

• Certificates
• Keys
• Lifecycles

Time, identity, and security are inextricably linked.

Experience from Practice

In a test system in the railway sector, NTS was used to:

• cryptographically secure time synchronization
• use time as a reliable basis for TLS connections
• operate safety-critical systems consistently

NTS was operated together with PKI and automated certificate management in a dedicated security partition.

This created a continuous chain of trust:

Identity → Certificate → Time → Communication

Conclusion

• Time is a security-critical parameter
• Classic NTP does not provide sufficient protection for it
• NTS makes time verifiable and trustworthy
• Without PKI, NTS cannot leverage its strengths

Time without trust is just a number that you «read off the clock». Only NTS turns it into a reliable foundation for security.