Time-based algorithms

Time drift

When time-based authenticator applications are used and because secrets are static, the Digipass authenticator needs to feed its crypto-engine with both the internal clock time and secrets to generate a dynamic password (or a signature).

The application settings define how often a new dynamic password is generated. This is the time step, which is the time unit for the time-based authenticator applications.

Ideally, the host and Digipass authenticator times are perfectly synchronized (identical). In this case, the host could only consider the current time step, corresponding to one dynamic password, and other dynamic passwords could be rejected.

Figure: Digipass and host times synchronized

In the real situation, the host and the Digipass authenticatortimes are not perfectly identical.

A time drift between the host and Digipass authenticator impacts the validity of dynamic passwords. The password validity is reduced to the first part of its original validity (see Figure: Time drift between host and Digipass authenticator - password validity reduced to first part).

Figure: Time drift between host and Digipass authenticator – password validity reduced to first part

If, for whatever reason, the time drift exceeds the time step value, a valid dynamic password will be rejected due to the time drift. The dynamic password is not valid during the current time step (see Figure: Time drift between host and Digipass authenticator - dynamic password not valid during current time step).

Figure: Time drift between host and Digipass authenticator – dynamic password not valid during current time step

With Authentication Suite Server SDK Time Drift Management, more than one dynamic password can be accepted as a valid password during a given period. This period is called the time window.

Figure: Time window

The time window determines the acceptable time drift. Its position may change every time the Digipass authenticator submits a successful dynamic password for validation. Authentication Suite Server SDK, in case of slow drifts, adjusts itself automatically, moving the time window center to the internal clock of the Digipass authenticator and storing the time shift synchronization information into the BLOB for this authenticator application.

To avoid any cumulative derivation scheme, the maximum time shift correction between two successful validations will be 1 second for each 6 hour-period elapsed between the two validations + 1 second whatever the period elapsed between these two validations.
Examples:
Two successful validations separated by one minute → maximum possible time shift correction after the second validation is one second.
Two successful validations separated by six hours and one minute → maximum possible time shift correction after the second validation is two seconds.
Two successful validations separated by one day and one minute → maximum possible time shift correction after the second validation is five seconds.

Figure: Time window – time drift correction

With this mechanism, the authenticator application BLOB is perfectly synchronized at any time with the Digipass authenticator. However, if the time drift between two successful authentications is too large, then Authentication Suite Server SDK will not be able to update the time synchronization. This happens rarely, e.g. as a result of big temperature differences or very long inactivity, in which case (and in production time window mode) the system administrator will need to reset the authenticator application with the Digipass Management Service.

Because of the reset functionality, the next authentication is considered as the first one. The initial synchronization time window calculates the initial time drift and stores this synchronization information into the authenticator application BLOB.

Synchronization time window

When a dynamic password (or a signature) is submitted for the very first time, Authentication Suite Server SDK does not know the (eventual) time drift for this Digipass authenticator.

This time difference may be caused by factors such as:

Bad host GMT time
The Digipass authenticator has not been used for a very long time.
The Digipass authenticator has been stored in a hostile environment (extreme humidity, heat, cold) before the first use.

After an import or a reset, the authenticator application BLOB is in initial synchronization time window mode. This implies that the following authentication will use the SyncWindow kernel parameter (expressed in hours or minutes) as a reference for the time window.

The default value for the SyncWindow is six hours (i.e., accept a drift of +/- three hours for the first authentication).

If this first authentication succeeds, the authenticator application BLOB changes to production time window mode: This production time window can be either static by default or dynamic.

A time-based Digipass authenticator is assumed to have a maximum time drift of +/- two seconds per day (+/- 730 seconds per year). A SyncWindow value of six hours supports a drift of +/- three hours (+/- 10,800 seconds). The initial synchronization will be possible even after 14 years, which is sufficient considering the lifetime of a Digipass authenticator.

Static time window

Authentication Suite Server SDK integrates a built-in mechanism to calculate the initial time drift between the Digipass authenticator and the host and to store it in the authenticator application BLOB.

When Authentication Suite Server SDK receives the first authentication or signature, it extracts the synchronization digits from the dynamic password and browses in the initial synchronization time window to check if the current password could be verified. If verification is possible, then Authentication Suite Server SDK will calculate the eventual drift and store it in the authenticator application BLOB. This information is called Deviation and is used for any password submission to move the time window center to correspond to the internal clock of the Digipass authenticator. If verification is not possible for the most probable time step unit, Authentication Suite Server SDK will iterate to the nearest next possible time step unit (alternatively lower and higher), until borders of the admissible time window are reached.

Figure: Insufficient iterations

When Authentication Suite Server SDK iterates to the nearest next possible time step unit, it tries to check the password again. Figure: Next iteration shows iteration over the next time step unit, which is wide enough to allow Authentication Suite Server SDK to validate the password.

Figure: Next iteration

If verification is possible, Authentication Suite Server SDK extracts the deviation (+1 time step unit in our example) and stores it back into the authenticator application BLOB.

In this case, each time this Digipass authenticator submits a password for validation, Authentication Suite Server SDK applies a +1 deviation for the time window to always keep the current time step in the middle of the time window.

Once the initial validation is done and successful, the validation time window size is switched to production time window mode for the next validations.

The production time window for authentication or signature validation is static by default (if the TW_DYNAMIC_WINDOWS flag is not used). As a consequence, the time window acceptance is static as well:

For authentication: Time Window (in seconds) = TimeStep x ITimeWindow.
For signature validation: Time Window (in seconds) = TimeStep x STimeWindow.

When defining the time window, the following should be taken into consideration:

What is the Digipass time step?
What is the frequency of use?
A Digipass authenticator is assumed to have a maximum time drift of +/- 2 seconds per day.

Bank X users use a time-based Digipass authenticator with a time step of 36 seconds, i.e. that is, the Digipass authenticator calculates a new OTP every 36 seconds. They assume that 100% of the users will use their Digipass authenticatorat least once every 180 days.
To calculate a good value for ITimeWindow (or STimeWindow in case of signature validation):
If a user uses their Digipass authenticator after 180 days of inactivity, the Digipass clock can drift by a maximum of +/- 360 seconds. To prevent a valid OTP from falling outside the window of valid OTPs (i.e., the ITimeWindow), this window must be set to greater than 720 seconds (+360 seconds for fast clocks or -360 seconds slow clocks) . However, because the ITimeWindow unit is the time step, you need to calculate this value as follows:
720 / 36 = 20 time steps
So ITimeWindow (or STimeWindow in case of signature validation) is calculated basically as follows:
( ( Max Expected Inactivity Days * Max DIGIPASS Time Drift per Day ) * 2 ) / DIGIPASS Time Step
If the value is not an even number, it must be rounded up to the next multiple of 2.

Digipass time step: 36 seconds
Max. expected inactivity period between 2 authentications: 30 days
Recommended ITimeWindow value: ((30*2)*2)/36 = 4 time steps

Digipass time step: 36 seconds
Max. expected inactivity period between two authentications: 180 days
Recommended ITimeWindow value: ((180*2)*2)/36 = 20 time steps

Dynamic time window

By default, the production time window for password and signature verification is a static time window. The purpose of this window is to balance the relative time drift between the Digipass clock and the server clock.

With the Dynamic Identification Time Window feature, the time window runtime parameter ITimeWindow (or STimeWindow) can be set relatively smaller than with the static version because the size of the production time window varies depending on the time span between two authentications (or two signatures) of one authenticator application.

If the user authenticates every day, the production time window (= number of acceptable OTPs) will remain small because the actual time drift is updated on a daily basis. If, however, a longer period elapses before the next validation, e.g., six months, the production time window will be extended to allow for the potential time drift.

This functionality is enabled by adding the flag TW_DYNAMIC_WINDOWS to the runtime parameters ITimeWindow and/or STimeWindow, for example:

ITimeWindow = 10 | TW_DYNAMIC_WINDOWS

STimeWindow = 10 | TW_DYNAMIC_WINDOWS

The following parameters affect the size of the dynamic time window:

Time step
Number of days since last successful OTP validation
ITimeWindow/STimeWindow kernel parameters
SyncWindow kernel parameter

Figure: Dynamic time window

With Dynamic Time Window enabled, the used TimeWindow after DWAT will grow by eight seconds per day (allowing possible drift between Digipass and the server up to +/- four seconds per day).

The time window will be extended after the DWAT, but not indefinitely.
The time window will be capped by the SyncWindow kernel parameter.

For an example of the dynamic time window, see Dynamic time window calculation examples.

Discrete synchronization time window

This feature was developed for OneSpan Mobile Security Suite.

Unlike a classic hardware Digipass authenticator (Digipass 300, Digipass GO 1 etc.), a mobile phone clock will change after daylight savings adjustment. With the discrete time window, Authentication Suite Server SDK supports this daylight savings adjustment and is able to accept an OTP generated on the mobile phone even with a time difference of +/- 1 hour.

Figure: Static time window

Figure: Discrete synchronization time window

With a static or dynamic time window, the purpose of the SyncWindow parameter is to define the time window accepted during the first authentication (or signature validation) or after a reset.

In the discrete synchronization time window mode, the purpose of the SyncWindow parameter is to determine the number of accepted discrete time windows. To support the daylight savings adjustment, SyncWindow must be set to 3 so that OTPs generated at GMT, GMT+1, or GMT-1 will be accepted.

This functionality is enabled by adding the SW_DISCRETE flag to the SyncWindow runtime parameter, for example, SyncWindow = 3 | SW_DISCRETE.