12 January 2019

Программируемые аппаратные TOTP ключи с возможностью синхронизации времени

Token2.com corporate blogInformation Security
Мы рады объявить о новой линейке программируемых аппаратных 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

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.

То есть, если сервер аутентификации соблюдает все предписания 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, аппаратный токен использовать уже не получится именно из-за разницы во времени. Причем батарея на токене, который не включался долгое время, емкости почти не теряет. Следовательно, и в данном случае, достаточно просто «подвести» на них часы, чтобы вернуть их в строй.

Анализ безопасности
Как всегда, такого рода новшества всегда основаны на балансе комфорта/удобства и уровня безопасности. Не являются исключением и программируемые ключи с возможностью синхронизации времени, от атак по сети (фишинг, человек посередине и т.д. — в большинстве случаев наши клиенты используют TOTP токены именно для защиты от такого рода атак) они конечно защитят в полной мере, но данная возможность предполагает малозначительную и чисто теоретическую вероятность атаки путём повтора (replay attack) с условием что злоумышленники могут:

  1. Получить первый фактор (пароль).
  2. Иметь физический доступ к аппаратному ключу без ведома владельца на протяжении достаточно долгого времени (см этап 3.).
  3. С помощью приложения, через NFC перевести время на ключе вперед на определенную дату, и записать достаточное количество сгенерированных кодов. Скриптом это реализовать не получится, так как для генерации кодов нужно нажать на физическую кнопку, а текущий код только подсмотреть на экране (по NFC он не передается).
  4. Вернуть время обратно (чтобы владелец ни о чем не догадался).
  5. И, наконец, выполнить вход в систему используя пароль (этап 1) и один из кодов полученных на этапе 3.

Данный риск, как видим, может возникнуть лишь при условии физического доступа к устройству, например, атаку сможет осуществить коллега сидящий рядом и по какой-то причине еще и знающий пароль. Но при таких условиях использование классических TOTP токенов приведет к такому же риску. К слову сказать, риск компрометации токенов с функцией синхронизации времени сравним с риском fido u2f девайсов — если злоумышленник временно и незаметно получил доступ к u2f ключу обладая при этом паролем, он может войти в систему с этим ключом, и добавить другой (свой) ключ и затем так же незаметно вернуть иходный ключ владельцу- по спецификации у одного акаунта может быть более одного u2f ключа, и любой можно использовать для параллельного входа. Такому же риску подвержены и факторы подобные Perfect paper passwords.
Как видите, атака довольно сложная и маловероятна, и в целом уровень риска использования таких токенов можно сравнить с использованием приложения типа Google Authenticator на смартфоне без пин-кода, не имеющим доступа в сеть и который пользователь всегда носит с собой.
Для клиентов, все же считающих даже этот риск достаточно большим наши рекомендации по этому поводу такие:
  1. Ограничивать физический доступ к такого типа ключам приблизительно так же как и к банковским картам (к слову сказать, наши ключи именно в формате банковских карт).
  2. Использовать программируемые ключи без функции синхронизации времени (miniOTP-1)
  3. Использовать программируемые ключи c функцией синхронизации времени, совмещенной с удалением секретного ключа. То есть, при изменении времени токена, seed будет обнулен и надо будет заносить его заново (miniOTP-3, о дате релиза модели будет обьявлено дополнительно)


Где купить?
Предзаказ открыт на нашем сайте. Используйте промокод HABR2019 для скидки 10% (количество купонов ограничено). Доставка обычной почтой (SwissPost или La Poste France). С доставкой в страны СНГ проблем до сих пор не возникало.
Tags:totpprogrammable hardware tokenstoken2
Hubs: Token2.com corporate blog Information Security
+3
2.5k 19
Comments 17