Мы рады объявить о новой линейке программируемых аппаратных TOTP ключей от TOKEN2. Основным нововведением является возможность синхронизации системных часов аппаратных ключей через NFC API с помощью специальных приложений — на данный момент готовится релиз под Android и Windows 10. Приложений под iOS пока нет: несмотря на то, что NFC чипы на последних моделях iPhone физически присутствуют, публичного API для их использования Apple пока не предоставляет.
Для чего это нужно?
В отличие от мобильных TOTP приложений, в аппаратных ключах нет возможности синхронизировать время по NTP, по сотовой сети или радио сигналу: аппаратные ключи устройства полностью изолированные и автономные, и в качестве источника точного времени используют часы на своей плате. В 1933-1934 гг. физики Шайбе и Адельсбергер из имперского физико-технического института в Берлине занялись возможностями использования пьезоэлектрического эффекта для измерения времени. Именно этот эффект и лежит в основе системных часов аппаратных ключей. Точность таких часов колеблется в пределах от ±0,3 до ±1.1 с/сутки в зависимости от качества. Если для обычных наручных часов этой точности достаточно, в аппаратных ключах разница во времени больше определенного лимита может привести к отказу в активации и/или аутентификации. Этот лимит зависит от конкретной системы (например Microsoft Azure MFA позволяет до 600 секунд смещения в обе стороны) когда дело касается первой регистрации аппаратного ключа. Далее, процесс синхронизации смещения в течении использования ключа для входа уже четко описан в RFC 6238
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.
То есть, если сервер аутентификации соблюдает все предписания RFC, и если ключ используется для аутентификации не слишком редко, например, хотя бы пару раз в год (точное число можно рассчитать формулой учитывающей точность осциллятора и допускаемого сервером смещения времени), то смещения времени будут учитываться на стороне сервера и проблем возникнуть не должно. При использовании ключей именно в таких условиях, функция синхронизации времени в принципе не нужна.
Однако, функция синхронизации времени может быть полезна в следующих случаях:
- Если серверная реализация TOTP не следует рекомендации RFC6238 №6. Одним из примеров такой реализации является DUO :
TOTP token drift and resynchronization are not supported. As a result, imported TOTP tokens may not work for authentication with Duo Security, or may fail to work for authentication after a variable period of time...
- Если партия аппаратных ключей была закуплена достаточно давно, но активировать их пришлось только через какое-то время — механизма синхронизации в таком случае во многих системах просто нет.
- Если аппаратный ключ используется для входа реже, чем нужно для синхронизации. Например, если пользователь хочет «скопировать» один и тот же TOTP профиль (точнее секретный ключ — shared secret) на два устройства: а) на мобильное приложение на телефоне для каждодневного использования и б) на программируемый аппаратный ключ в качестве резервного, на черный день. Таким образом, если этот черный день наступит года через 3-4, аппаратный токен использовать уже не получится именно из-за разницы во времени. Причем батарея на токене, который не включался долгое время, емкости почти не теряет. Следовательно, и в данном случае, достаточно просто «подвести» на них часы, чтобы вернуть их в строй.
- Получить первый фактор (пароль).
- Иметь физический доступ к аппаратному ключу без ведома владельца на протяжении достаточно долгого времени (см этап 3.).
- С помощью приложения, через NFC перевести время на ключе вперед на определенную дату, и записать достаточное количество сгенерированных кодов. Скриптом это реализовать не получится, так как для генерации кодов нужно нажать на физическую кнопку, а текущий код только подсмотреть на экране (по NFC он не передается).
- Вернуть время обратно (чтобы владелец ни о чем не догадался).
- И, наконец, выполнить вход в систему используя пароль (этап 1) и один из кодов полученных на этапе 3.
Данный риск, как видим, может возникнуть лишь при условии физического доступа к устройству, например, атаку сможет осуществить коллега сидящий рядом и по какой-то причине еще и знающий пароль. Но при таких условиях использование классических TOTP токенов приведет к такому же риску. К слову сказать, риск компрометации токенов с функцией синхронизации времени сравним с риском fido u2f девайсов — если злоумышленник временно и незаметно получил доступ к u2f ключу обладая при этом паролем, он может войти в систему с этим ключом, и добавить другой (свой) ключ и затем так же незаметно вернуть иходный ключ владельцу- по спецификации у одного акаунта может быть более одного u2f ключа, и любой можно использовать для параллельного входа. Такому же риску подвержены и факторы подобные Perfect paper passwords.
Как видите, атака довольно сложная и маловероятна, и в целом уровень риска использования таких токенов можно сравнить с использованием приложения типа Google Authenticator на смартфоне без пин-кода, не имеющим доступа в сеть и который пользователь всегда носит с собой.
Для клиентов, все же считающих даже этот риск достаточно большим наши рекомендации по этому поводу такие:
- Ограничивать физический доступ к такого типа ключам приблизительно так же как и к банковским картам (к слову сказать, наши ключи именно в формате банковских карт).
- Использовать программируемые ключи без функции синхронизации времени (miniOTP-1)
Комментарии (16)
Grey4ip
12.01.2019 23:18+1А почему разрешено изменять время по nfc (вашим приложением) без индивидуального пароля TOTP ключа?
EminH
12.01.2019 23:25+1я понимаю это вопрос не только по данной модели, но вообще по всем программируемым токенам (на других можно менять только секретный ключ).
думаю можно это обьяснить стремлением к упрощению процесса, опять же не забываем про баланс- на одной чаше комфорт пользователя и логистика/организация процесса установки индивидуального пароля на каждый токен (плюс механизм восстановления), на другой потенциальный риск компромизации через NFCGrey4ip
12.01.2019 23:36+1Понятно. Как вариант, можно, чтобы приложение получало «время + соль» в зашифрованном виде с ваших серверов, а расшифровка проходила непосредственно на самом ключе. И для каждого серийного номера ключа свой ключ шифрования.
EminH
12.01.2019 23:43я понимаю с асинхронным шифрованием? хорошая идея
Одна проблема- многие клиенты с подозрением отнесутся к самой идее обмена данными со сторонними серверами. В нынешнем варианте, комп с софтом для прошивки может работать в оффлайне — так можно быть уверенным что ничего (а в частности секретные ключи) никуда не отсылаются
dreesh
13.01.2019 07:06А разве нельзя ограничить перевод времени только вперед? А если вдруг в ключе часы спешат «замораживать» устройство (не давать использовать устройство пока часики не оттикают разницу) тем самым предотвратив компрометацию будущих ключей, а точнее создать условия в которых будет очевиден факт компрометации устройства.
EminH
13.01.2019 10:28А как определять спешат или нет? Сравнивать же не с чем
dreesh
13.01.2019 10:35При синхронизации часов по NFC мы знаем точное время, не? Если ключ обнаруживает наличие опережения своих часов и знает, как давно была последняя синхронизация, то он может сравнить на основе примерной точности своего кварца (теоретически возможное расхождение секунд) реальное ли ему дают время или пытаются применить атаку повтора.
EminH
13.01.2019 10:52Понятно, то есть надо хранить лог изменений времени, причём именно лог так как точность осциллятора тоже не константа и меняется в зависимости от разных факторов. Там логи хранить просто негде, мы лишние пару байтов не можем разместить для хранения сида (сейчас максим. длина 32 символа base32) — иначе увеличивается размеры и цена
Можно в принципе не усложнять и просто ограничить окно изменений — например точностью помноженной на жизнь батареи (например при максимально возможном смещении в 2 минуты в год и сроком аккумулятора 5 лет — разрешать не более 10 минут в каждую сторону).
Вы считаете риск существенным? Ведь он ровно такой же как при утере обычного ключа (без синхронизации времени) — только атка должна будет осуществлена сразу (в течении 5-10 минут) а не через неделю, например. Стоят ли свеч усилия по ограничению изменения времени в таком случае?
herrjemand
20 евро за OTP токен? За такие деньги можно купить полноценный ключ безопасности, а то и два. И он не будет подвержен атаке посередине, фишингу, атаке повтором. Не говоря о легкости применения и возможности беспарольной аутентификации.
EminH
Вы про FIDO/FIDO2? если так, то можно еще дешевле найти (Token2 скоро запустит u2f по цене около 8-10 евро). Только некорректно их сравнивать, это разные устройства, и u2f/fido2 пока не везде поддерживаются. Теоретически, такие ключи конечно удобнее для пользователя (при определенной комбинации условий) и дешевле (нет дисплея и даже батареи, и один ключ можно использовать лет 10-15 на разных акаунтах), но видимо из-за сложности реализации, TOTP все еще популярнее.
herrjemand
Данное решение тоже как-то не стандартно, и тоже требует отдельного аппаратного комплекса. Базовая реализация FIDO не сложнее чем TOTP. Поддержка была лимитированна из-за отсутствия поддержки браузером, но и сие сейчас решено.
EminH
чему я лично рад несказанно (я тоже фанат идей FIDO и u2f мне использовать гораздо удобнее)
но я все еще считаю что сравнивать например u2f и TOTP некорректно, они не всегда взаимозаменяемы