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:
- Tolerance is 86400 seconds.
- Frequency is 86400 seconds.
- Your licenses expire on 24 hour boundaries.
- You don't use start time in licenses.
This may lead to the following questions:
- 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?
- If a customer could somehow windback each day by < 24 hours, it is possible for them to steal the license?
- 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?
- 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:
- 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.
- Yes, it is possible given their settings. However, you should consider changing the frequency to zero.
- Yes, if license goes into expiry before windback detection and customer notices this and performs windback to < 24 hours, the license will resume.
- 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:
- A capability response being processed into trusted storage.
- 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.
Related Articles
How do You Repair a Trusted Storage Activation When it's in The **DISABLED** State? 5Number of Views Cannot Acquire License from Trusted Storage After Restart 9Number of Views Adding a New Platform to FlexNet Embedded (updating vendor keys) 14Number of Views Clock-Windback Detection with a FlexNet Embedded Client 10Number of Views Welcome, FlexNet Publisher Newcomers! 20Number of Views
Hi, I am Reva - Ask me anything.
No new updates
Thanks for the feedback!
Your feedback has been saved.Rate this response:
Add Additional feedback ( Optional )
Are you sure you want to cancel
the case creation?
Are you sure you want to cancel the case creation?
Are you sure you want to close this case
| Products | Region | Phone Numbers |
|---|---|---|
| FlexNet Operations FlexNet Embedded FlexNet Publisher FlexNet Connect FlexNet Code Insight InstallAnywhere InstallShield |
North America * |
+1 630-332-2513 (toll) +1 877-279-2853 (toll-free in North America) |
| Europe * |
+44 1925 944367 (toll) +44 800 047 8642 (toll-free in Europe) |
|
| Japan * | +81 3-4540-5335 (select option 2) | |
| Australia * |
+61 3 9895 2177 +61 1800 560 603 (toll-free in Australia) |
|
|
Usage Intelligence (formerly
Revulytics) Compliance Intelligence |
Please use the Case Portal to submit your support ticket or reach out to your Revenera contact. | |
Case id: 00001065
Activity: Status change: 2 hours ago