Time syncronization
DiME, the open and trust-based data format building secure Application-based Public-Key Infrastructures (APKIs) in a breeze.
When working with issued at dates and expires at dates as DiME does, problems around time synchronization may start to be apparent. This since a client with a time off with just a few seconds could mean that a message seems to be expired, even if it is still very much valid, or it may look like responses coming in are from the future.
Just like with DiME, there is no built-in solution for problems related to time synchronization in standards such as X.509 for digital certificates. However, for digital certificates, this problem is more minor as certificates are valid for a more extended period.
The DiME reference implementation includes several tools to handle time synchronization issues.
There is one situation where the problem may be easily noticed, at the time of creating and signing a new certificate.
However, a newly issued certificate still suffers from a time problem. A recent notBefore date may be in the future from the receiving client’s perspective if it is running behind in time to the issuing server. This means that the client may have to wait before starting using it. Some Certificate Authorities (CAs) therefore issue certificates with a notBefore date 10 minutes into the past for exactly this reason. These tactics provide a 10-minute error margin for any time differences.
The same solution can be utilized with DiME, where Identities would be issued with an issued at (iat) date 10 minutes in the past, from the server’s perspective. This will allow an issued Identity to be used immediately. This assumes that no entity in the network is more than 10 minutes behind the issuing server.
SSL/TLS also avoids the issue of time differences between devices. However, during the handshake, the client and server exchange 32 random bytes where the four first bytes encode the current date. Why is not clearly explained, and perhaps this could be used for understanding the difference in time between the devices. However, many usages do not follow this, so it makes it unreliable as a source for the current time.
Furthermore, neither SSL nor TLS considers the validation of the certificate to be within the scope of the specifications. It is just assumed that the client validates the certificate. This does open for situations where the handshake would fail due to differences in time.
Synchronizing time
It is not possible to use the 10-minutes-into-the-past solution when sending short-lived messages. Here differences in seconds could still present severe problems.
There are at least two things that need to be done to solve the problem of time differences between devices. Firstly, time needs to be synced between all devices, and secondly, some slack needs to be added when comparing two timestamps.
The simplest solution to synchronize time is to have all networked devices use the same time server (NTP-server). Each device would request the current time from the NTP-server and adjust its local time. Time differences between different time servers tend to be minor, so using different time servers may also be an option.
Sometimes it may not be practical or even possible to use a time server. In this scenario, it would be possible for clients to synchronize their times with a central server.
This approach requires at least three timestamps to synchronize with and would result in a somewhat accurate time between two devices. The client that wishes to synchronize its time with the server would capture its own current time just before requesting a timestamp from the server. Then when the client receives the response with the server’s time, it would capture a second timestamp.
Using these three timestamps, the client would then calculate a delta for how much ahead or behind it is compared to the time from the server.
Firstly, consideration must be given to the round-trip time and any latency, this is done by subtracting the first local timestamp from the second local timestamp and dividing the result by 2. This is an approximation, which turns out to be fairly accurate.
Then the delta is calculated by subtracting the second local timestamp with the server time and adding the consideration for the request trip time.
Once the delta has been calculated it should be added to any timestamps captured by the client. The time will still not be exact between the client and server, but it should not be off by more than a second or so.
Avoiding edge cases
Even if the time is synchronized between a client and a server, there exists the possibility of improperly disqualifying a received message. This may happen both at the start, issued at, and at the end, expires at, of the validity period if any of the communicating devices are a second or so behind or ahead of the other.
The likelihood of a device being behind or ahead with just one or two seconds is quite high, even if they are time-synchronized. This could be due to the imprecise measurement when calculating the request trip time and if synchronizing on seconds or milliseconds.
To compensate for this impreciseness, it is possible to compare timestamps with a small grace margin, one or two seconds in either direction.
This would mean that the validity period, between the issued date and the expiration date, is extended by a few seconds in either direction.
Working with a grace margin is only effective if the communicating devices are already time-synchronized. If they are not, its usefulness is limited.
Time is always a problem, which may sometimes create difficult to debug problems or rejections that are hard to explain. Incorporating the ideas outlined here may make working with time a little less frustrating, unfortunately, it won’t solve it altogether.
Last updated