Programmable hardware TOTP keys with the ability to synchronize time
We are pleased to announce a new line of programmable hardware TOTP keys from TOKEN2. The main innovation is the ability to synchronize the system clock hardware keys via the NFC API using special applications - at the moment is preparing a release for Android and Windows 10.There are no applications for iOS yet: despite the fact that NFC chips are physically present on the latest iPhone models, Apple does not yet provide a public API for their use.
What is it for?
Unlike mobile TOTP applications, hardware keys do not have the ability to synchronize time over NTP, over a cellular network or radio signal: the device hardware keys are completely isolated and autonomous, and use a clock on their board as a source of accurate time. In 1933-1934 physicists Scheibe and Adelsberger of the Imperial Physics and Technology Institute in Berlin took up the possibilities of using the piezoelectric effect to measure time. It is this effect that underlies the system clock of the hardware keys. The accuracy of such hours varies from ± 0.3 to ± 1.1 s / day, depending on the quality. If this accuracy is sufficient for ordinary wristwatches, in hardware keys, the time difference more than a certain limit may lead to a failure in activation and / or authentication. This limit depends on the specific system (for example, Microsoft Azure MFA allows up to 600 seconds bias to both sides) when it comes to first registering a hardware key. Further, the process of synchronizing the bias during the use of the key for entry is already clearly described inRFC 6238
RFC 6238 / 6. Resynchronization
Because of possible clock drifts between a client and a validation
server, we RECOMMEND that the validator be set with a specific limit
to the number of time steps a prover can be «out of synch» before
being rejected.
This limit can be set both forward and backward from the calculated
time step on receipt of the OTP value. If the time step is
30 seconds as recommended, and the validator is set to only accept
two time steps backward, then the maximum elapsed time drift would be
around 89 seconds, i.e., 29 seconds in the calculated time step and
60 seconds for two backward time steps.
This would mean the validator could perform a validation against the
current time and then two further validations for each backward step
(for a total of 3 validations). Upon successful validation, the
validation server can record the detected clock drift for the token
in terms of the number of time steps. When a new OTP is received
after this step, the validator can validate the OTP with the current
timestamp adjusted with the recorded number of time-step clock drifts
for the token.
Also, it is important to note that the longer a prover has not sent
an OTP to a validation system, the longer (potentially) the
accumulated clock drift between the prover and the verifier. In such
cases, the automatic resynchronization described above may not work
if the drift exceeds the allowed threshold. Additional
authentication measures should be used to safely authenticate the
prover and explicitly resynchronize the clock drift between the
prover and the validator.
server, we RECOMMEND that the validator be set with a specific limit
to the number of time steps a prover can be «out of synch» before
being rejected.
This limit can be set both forward and backward from the calculated
time step on receipt of the OTP value. If the time step is
30 seconds as recommended, and the validator is set to only accept
two time steps backward, then the maximum elapsed time drift would be
around 89 seconds, i.e., 29 seconds in the calculated time step and
60 seconds for two backward time steps.
This would mean the validator could perform a validation against the
current time and then two further validations for each backward step
(for a total of 3 validations). Upon successful validation, the
validation server can record the detected clock drift for the token
in terms of the number of time steps. When a new OTP is received
after this step, the validator can validate the OTP with the current
timestamp adjusted with the recorded number of time-step clock drifts
for the token.
Also, it is important to note that the longer a prover has not sent
an OTP to a validation system, the longer (potentially) the
accumulated clock drift between the prover and the verifier. In such
cases, the automatic resynchronization described above may not work
if the drift exceeds the allowed threshold. Additional
authentication measures should be used to safely authenticate the
prover and explicitly resynchronize the clock drift between the
prover and the validator.
That is, if the authentication server complies with all RFC prescriptions, and if the key is used for authentication is not too rare, for example, at least a couple of times a year (the exact number can be calculated using the accuracy of the oscillator and the time offset allowed by the server), then time offsets will be taken into account on the server side and problems should arise. When using keys in such conditions, the time synchronization function is basically not needed.
However, the time synchronization function can be useful in the following cases:
- If the server implementation of TOTP does not follow RFC6238 recommendation # 6. One example of such an implementation is DUO :
TOTP token drift and resynchronization are not supported. It is not necessary to work with the author, but may not have to
- If a batch of hardware keys was purchased a long time ago, but they had to be activated only after some time - in this case there is simply no synchronization mechanism in many systems.
- If the hardware key is used to log in less frequently than is needed for synchronization. For example, if a user wants to “copy” the same TOTP profile (more precisely, the secret secret key) to two devices: a) to a mobile application on the phone for everyday use and b) to a programmable hardware key as a backup for a rainy day . Thus, if this rainy day comes in 3-4 years, the hardware token will no longer be used precisely because of the time difference. And the battery on the token, which has not been turned on for a long time, almost does not lose capacity. Consequently, in this case, it is enough just to “set” the clock on them in order to return them to the system.
Security analysis
Как всегда, такого рода новшества всегда основаны на балансе комфорта/удобства и уровня безопасности. Не являются исключением и программируемые ключи с возможностью синхронизации времени, от атак по сети (фишинг, человек посередине и т.д. — в большинстве случаев наши клиенты используют TOTP токены именно для защиты от такого рода атак) они конечно защитят в полной мере, но данная возможность предполагает малозначительную и чисто теоретическую вероятность атаки путём повтора (replay attack) с условием что злоумышленники могут:
Данный риск, как видим, может возникнуть лишь при условии физического доступа к устройству, например, атаку сможет осуществить коллега сидящий рядом и по какой-то причине еще и знающий пароль. Но при таких условиях использование классических TOTP токенов приведет к такому же риску. К слову сказать, риск компрометации токенов с функцией синхронизации времени сравним с риском fido u2f девайсов — если злоумышленник временно и незаметно получил доступ к u2f ключу обладая при этом паролем, он может войти в систему с этим ключом, и добавить другой (свой) ключ и затем так же незаметно вернуть иходный ключ владельцу- по спецификации у одного акаунта может быть более одного u2f ключа, и любой можно использовать для параллельного входа. Такому же риску подвержены и факторы подобные Perfect paper passwords.
Как видите, атака довольно сложная и маловероятна, и в целом уровень риска использования таких токенов можно сравнить с использованием приложения типа Google Authenticator на смартфоне без пин-кода, не имеющим доступа в сеть и который пользователь всегда носит с собой.
Для клиентов, все же считающих даже этот риск достаточно большим наши рекомендации по этому поводу такие:
- Получить первый фактор (пароль).
- Иметь физический доступ к аппаратному ключу без ведома владельца на протяжении достаточно долгого времени (см этап 3.).
- С помощью приложения, через NFC перевести время на ключе вперед на определенную дату, и записать достаточное количество сгенерированных кодов. Скриптом это реализовать не получится, так как для генерации кодов нужно нажать на физическую кнопку, а текущий код только подсмотреть на экране (по NFC он не передается).
- Вернуть время обратно (чтобы владелец ни о чем не догадался).
- И, наконец, выполнить вход в систему используя пароль (этап 1) и один из кодов полученных на этапе 3.
Данный риск, как видим, может возникнуть лишь при условии физического доступа к устройству, например, атаку сможет осуществить коллега сидящий рядом и по какой-то причине еще и знающий пароль. Но при таких условиях использование классических TOTP токенов приведет к такому же риску. К слову сказать, риск компрометации токенов с функцией синхронизации времени сравним с риском fido u2f девайсов — если злоумышленник временно и незаметно получил доступ к u2f ключу обладая при этом паролем, он может войти в систему с этим ключом, и добавить другой (свой) ключ и затем так же незаметно вернуть иходный ключ владельцу- по спецификации у одного акаунта может быть более одного u2f ключа, и любой можно использовать для параллельного входа. Такому же риску подвержены и факторы подобные Perfect paper passwords.
Как видите, атака довольно сложная и маловероятна, и в целом уровень риска использования таких токенов можно сравнить с использованием приложения типа Google Authenticator на смартфоне без пин-кода, не имеющим доступа в сеть и который пользователь всегда носит с собой.
Для клиентов, все же считающих даже этот риск достаточно большим наши рекомендации по этому поводу такие:
- Ограничивать физический доступ к такого типа ключам приблизительно так же как и к банковским картам (к слову сказать, наши ключи именно в формате банковских карт).
- Использовать программируемые ключи без функции синхронизации времени (miniOTP-1)
- Использовать программируемые ключи c функцией синхронизации времени, совмещенной с удалением секретного ключа. То есть, при изменении времени токена, seed будет обнулен и надо будет заносить его заново (miniOTP-3, о дате релиза модели будет обьявлено дополнительно)
Where can one buy?
Предзаказ открыт на нашем сайте. Используйте промокод HABR2019 для скидки 10% (количество купонов ограничено). Доставка обычной почтой (SwissPost или La Poste France). С доставкой в страны СНГ проблем до сих пор не возникало.