Summary

Clock Windback Detection Implementation Example

Question

In an effort to understand how robust your setup may be, and whether or not the settings should be tweaked to meet your business needs, here's an example of the thought process behind setting-up a clock windback detection implementation.

Assume you're enabling it using the following parameters:

1. Tolerance is 86400 seconds.
2. Frequency is 86400 seconds.
3. Your licenses expire on 24 hour boundaries.
4. You don't use start time in licenses.

This may lead to the following questions:

1. If trusted storage is written sometime before the next 86400 frequency interval, will the saved timestamp be updated as a result of writing to the trusted storage and the interval reset?
2. If a customer could somehow windback each day by < 24 hours, it is possible for them to steal the license?
3. If a license goes into expiry before windback detection, and the customer notices this and performs windback to < 24 hours, will the license resume working?
4. If you go into windback, and then the clock is moved such that it's valid again, would licensing be usable again?

Are the above settings good for reasonable detection, considering you're deploying in a variety of environments where the you don't want the clock to be too strict and break licensing (hence the choice of 86400 seconds?

Answer

The relevant section of the documentation is as follows:

"The windback tolerance setting limits the number of seconds? difference allowed without triggering a clockwindback state. The windback frequency setting is a number of seconds between updates to the stored timestamp. Normally, the timestamp will be updated for any time-sensitive event (such as acquiring a license or processing trial rights or a new capability response), but setting a larger interval may be desirable when working with machines on which frequent writes to the trusted storage anchor are unacceptable or unnecessary. Setting the frequency to zero indicates that the anchor will be updated every time clock-windback detection occurs, whether explicitly or implicitly."

The tolerance is saying: that's how much wind back I'll accept.

The frequency is saying: this is how often I'll update the wind back value (although only if acquire is called; there are no background threads in FNE).

Direct answers to the questions regarding this specific scenario above would be as follows:

1. The timestamp will be updated if the <current transaction timestamp> is greater than <current anchor time> + <frequency>. So, no, the saved timestamp (the anchor) will not be updated and the interval will not be reset in the situation described.
2. Yes, it is possible given their settings. However, you should consider changing the frequency to zero.
3. Yes, if license goes into expiry before windback detection and customer notices this and performs windback to < 24 hours, the license will resume.
4. Yes, if you go into windback, and the clock is moved such that it's valid again, the license will be usable. The check is performed at the time of license acquisition.

It's not so much about trusted storage being written as when the anchor time is updated in the anchor store. Two main events cause that:

1. A capability response being processed into trusted storage.
2. A license acquire, assuming that currentTime > windbackTime + windbackFrequency

Windback is true if at any point windbackTime > currentTime + windbackTolerance

In this case, with the customer having licenses which expire at the end of the day, these values don't make much sense. The only thing having windback enabled is doing for the producer here is preventing the customer winding back his clock by more than tolerance.

Tolerance should be set according to the nature of the device and the reliability of it's clock for how much correction happens. Frequency is realistically how often the recorded value marches forward: the more often, the less the scope for windback to happen.