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. As shown in Figure: Time drift between host and Digipass authenticator - password validity reduced to first part, the password validity is reduced to the first part of its original validity.

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. As shown in Figure: Time drift between host and Digipass authenticator - dynamic password not valid during current time step, the dynamic password is not valid during the 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.