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