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

    Мы рады объявить о новой линейке программируемых аппаратных 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). С доставкой в страны СНГ проблем до сих пор не возникало.
    Token2.com
    98,00
    Компания
    Поделиться публикацией

    Комментарии 16

      +1

      20 евро за OTP токен? За такие деньги можно купить полноценный ключ безопасности, а то и два. И он не будет подвержен атаке посередине, фишингу, атаке повтором. Не говоря о легкости применения и возможности беспарольной аутентификации.

        0
        полноценный ключ безопасности

        Вы про FIDO/FIDO2? если так, то можно еще дешевле найти (Token2 скоро запустит u2f по цене около 8-10 евро). Только некорректно их сравнивать, это разные устройства, и u2f/fido2 пока не везде поддерживаются. Теоретически, такие ключи конечно удобнее для пользователя (при определенной комбинации условий) и дешевле (нет дисплея и даже батареи, и один ключ можно использовать лет 10-15 на разных акаунтах), но видимо из-за сложности реализации, TOTP все еще популярнее.
          –1

          Данное решение тоже как-то не стандартно, и тоже требует отдельного аппаратного комплекса. Базовая реализация FIDO не сложнее чем TOTP. Поддержка была лимитированна из-за отсутствия поддержки браузером, но и сие сейчас решено.

            +1
            Данное решение тоже как-то не стандартно
            никак нет, все полностью стандартно. это полноценная замена приложениям типа Google Authenticator, только логиниться потом можно будет только с применением самого токена, без смартфона
            отсутствия поддержки браузером, но и сие сейчас решено
            чему я лично рад несказанно (я тоже фанат идей FIDO и u2f мне использовать гораздо удобнее)
            но я все еще считаю что сравнивать например u2f и TOTP некорректно, они не всегда взаимозаменяемы
        +1
        А почему разрешено изменять время по nfc (вашим приложением) без индивидуального пароля TOTP ключа?
          +1
          я понимаю это вопрос не только по данной модели, но вообще по всем программируемым токенам (на других можно менять только секретный ключ).

          думаю можно это обьяснить стремлением к упрощению процесса, опять же не забываем про баланс- на одной чаше комфорт пользователя и логистика/организация процесса установки индивидуального пароля на каждый токен (плюс механизм восстановления), на другой потенциальный риск компромизации через NFC
            +1
            Понятно. Как вариант, можно, чтобы приложение получало «время + соль» в зашифрованном виде с ваших серверов, а расшифровка проходила непосредственно на самом ключе. И для каждого серийного номера ключа свой ключ шифрования.
              0
              я понимаю с асинхронным шифрованием? хорошая идея
              Одна проблема- многие клиенты с подозрением отнесутся к самой идее обмена данными со сторонними серверами. В нынешнем варианте, комп с софтом для прошивки может работать в оффлайне — так можно быть уверенным что ничего (а в частности секретные ключи) никуда не отсылаются
                0
                Да. Согласен. Тогда добавить опцию добавления пароля (на ключ) на установку времени/секретного ключа. Кому надо, тот установит пароль.
                  0
                  это надо делать на уровне чипа, что приведет к удорожанию продукта.
              0
              А разве нельзя ограничить перевод времени только вперед? А если вдруг в ключе часы спешат «замораживать» устройство (не давать использовать устройство пока часики не оттикают разницу) тем самым предотвратив компрометацию будущих ключей, а точнее создать условия в которых будет очевиден факт компрометации устройства.
                0

                А как определять спешат или нет? Сравнивать же не с чем

                  0
                  При синхронизации часов по NFC мы знаем точное время, не? Если ключ обнаруживает наличие опережения своих часов и знает, как давно была последняя синхронизация, то он может сравнить на основе примерной точности своего кварца (теоретически возможное расхождение секунд) реальное ли ему дают время или пытаются применить атаку повтора.
                    0
                    Понятно, то есть надо хранить лог изменений времени, причём именно лог так как точность осциллятора тоже не константа и меняется в зависимости от разных факторов. Там логи хранить просто негде, мы лишние пару байтов не можем разместить для хранения сида (сейчас максим. длина 32 символа base32) — иначе увеличивается размеры и цена
                    Можно в принципе не усложнять и просто ограничить окно изменений — например точностью помноженной на жизнь батареи (например при максимально возможном смещении в 2 минуты в год и сроком аккумулятора 5 лет — разрешать не более 10 минут в каждую сторону).

                    Вы считаете риск существенным? Ведь он ровно такой же как при утере обычного ключа (без синхронизации времени) — только атка должна будет осуществлена сразу (в течении 5-10 минут) а не через неделю, например. Стоят ли свеч усилия по ограничению изменения времени в таком случае?
            0
            единственный в мире, серийно выпускающийся аппаратный TOTP токен с возможностью синхронизации времени.

            Так что, впереди планеты всей?

              0
              Не нашли аналогов во всяком случае. Сноску что ли добавить чтобы не раздражало никого?

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое