SecurePass and Clock Skew

One of the most frequently asked question I usually receive is how we qualify an hardware vendor for our hardware tokens. We are “picky” on choosing the hardware tokens as we want to ensure the maximum security while accessing our SecurePass platform.

The real difference between a “good” hardware token and a “bad” one is all about the endurance of the battery and the quartz precision over a 3 years timeframe. Why quartz?

Let’s step back and see how OTP works in SecurePass. We are embracing a public algorithm called TOTP, i.e. Time-Based One-Time Password Algorithm. We decided to use a public algorithm as it has been reviewed by security experts and might be more robust than a proprietary one. We -as GARL- don’t believe in security through obscurity.

TOTP is a variance of HOTP, in which the OTP is generated by a seed (the shared secret) and an Initialization Vector (IV), that is a simple 8 byte counter.

HOTP has the issue of desynchronizing the counter if the user press too many times the button on the hardware token, generating more support calls for resets or -even worse- by increasing the tolerance between number of valid counters.

I won’t name it, but in an Italian bank HOTP generated so many issues, that they need to increase the number of valid counters as people kept their hardware token in their keychain and they were inadvertently pressing the button. Increasing tolerance of counters will lead in less security, as a brute-force program could potentially hit a valid OTP code.

TOTP uses Unix Time as IV, it has less issues than HOTP, but time synchronization is crucial when using this algorithm. The tolerance in TOTP is called “clock skew”, i.e. the time difference between the server and the device. RFC6238, i.e. the TOTP standard, recommends looking an extra time step in either direction, which essentially opens the window from 30 seconds to 90 seconds.

As you might understand, the less “skew”, the better security. While this is not an issue on mobile tokens, whose time is generally synchronized through the mobile network, it is for the hardware token.

We are so “picky” on choosing an hardware token as it needs to pass our tests, we want to be our quartz as much precise as possible to ensure the maximum security to the end users, while ensuring a fair price.

See also: