Физические U2F ключи безопасности — Что это? | Портал о системах видеонаблюдения и безопасности

Почему это здорово

Если мы посмотрим на критику независимого бэкап-токена, изложенную выше, мы можем увидеть, что все недостатки этого метода оказываются устранены:

  • Бэкап-токен больше не должен быть легкодоступным. Экстремальными примерами могут быть: замуровать токен внутрь кирпичной стены, или закопать на полтора метра в саду или еще где-нибудь. Без шуток, я вполне готов пойти на это;
  • Вне зависимости от того, где я нахожусь, если я регистрируюсь на каком-либо сервисе, мне не нужно делать ровно ничего, чтобы добавить бэкап-токен на этот сервис. Я просто использую мой основной токен, и нахожусь в душевном спокойствии, зная, что у меня есть бэкап;
  • Для посторонних лиц совершенно неочевидно, где находится мой бэкап-токен. Даже зная, что он существует, пытаться его найти самостоятельно вряд ли имеет смысл;
  • Это достаточно безопасно. Даже если что-то плохое случится с моим основным токеном, крайне маловероятно, что это же происшествие затронет и бэкап-токен;
  • Это универсально. Такой метод бэкапа будет работать на любом сервисе с поддержкой U2F, независимо от того, что еще поддерживает этот сервис.

И если с основным токеном действительно случится что-то плохое, то я делаю следующее:

  • Откапываю / размуровываю бэкап-токен;
  • Аутентифицируюсь на всех своих сервисах с U2F, тем самым аннулируя основной токен;
  • Заказываю новую пару токенов, и после получения, добавляю новый основной токен на всех сервисах, и отзываю старый.


По крайней мере, для меня лично эта стратегия — отличный компромисс для высокого уровня безопасности и необременительного бэкапа. Это более безопасно и более надежно, чем любой другой метод.

Основная идея

Идея заключается в следующем: на этапе производства, запрограммировать два токена таким образом, что они оба имеют одинаковый

device_secret

, но бэкап-токен нуждается в некоторой коррекции: вместо того, чтобы использовать

counter

в чистом виде (как делают обычные токены), он должен добавить некоторую большую константу к

counter

. Например, половина 32-битного диапазона, т.е. примерно

2 000 000 000

, выглядит разумно: я вряд ли исчерпаю такое количество аутентификаций за всю жизнь.

Фактически, это все. Просто и эффективно.

Имея два токена запрограммированных таким образом, я прячу бэкап-токен в какое-нибудь реально труднодоступное место, и никогда его не трогаю. Если что-то ужасное случается и я утрачиваю доступ к основному токену, я таки добираюсь до бэкап-токена, и сразу могу использовать его на всех сервисах, где я регистрировал основной токен, т.к. бэкап имеет тот же самый device_secret, и его counter начинается с реально большого числа, до которого я не доберусь на протяжение всей жизни.

Также, обращаю внимание, что я не предлагаю делать токены клонируемыми. Два токена, хотя и обладают одинаковым device_secret, имеют разные счетчики, и после программирования device_secret не должно быть способа получить его обратно из устройства или каким-либо другим образом создать клон.

Введение

JaCarta U2F — универсальный ключевой носитель, обеспечивающий усиленную двухфакторную аутентификацию и дополняющий парольную защиту для различных онлайн-сервисов.

JaCarta U2F входит в состав семейства аппаратных и программных продуктов JaCarta компании «Аладдин Р. Д.». Обзор платформы JaCarta ранее публиковался на нашем сайте.

JaCarta U2F полностью соответствует спецификациям стандарта FIDO U2F (Universal 2nd Factor, универсальный второй фактор), разработанного альянсом компаний, заинтересованных в развитии надежной аутентификации в интернете.

В состав Альянса FIDO входят крупные компании-разработчики (NXP, ARM, Infineon, Samsung, RSA, Blackberry, Google, Microsoft, GitHub, WordPress и др.), финансовые организации и платежные системы (Bank of America, Goldman Sachs, MasterCard, VISA, PayPal, AliPay и др.), поставщики онлайн-услуг и торговые площадки (Google, AliExpress Group, Microsoft, Alibaba group и др.). Также членом Альянса FIDO является российская компания «Аладдин Р. Д.».

Пользователь может применять один и тот же U2F-токен для доступа к различным интернет-ресурсам, поддерживающим стандарт FIDO U2F. При этом внутри токена для каждого ресурса создается новая ключевая пара, используемая для взаимодействия только с этим ресурсом.

Открытый ключ из этой пары передается проверяющей стороне (целевому ресурсу) для привязки к учетной записи пользователя. Пользователь самостоятельно регистрирует свой токен на интересующих его интернет-ресурсах, снижая нагрузку на администратора. Когда пользователь аутентифицируется, то, помимо проверки учетных данных пользователя (имени и пароля), целевой сайт проверяет наличие у пользователя зарегистрированного в профиле U2F-токена, установив корректность ассоциированного ключа.

Архитектура системы аутентификации на базе jacarta u2f

Рисунок 2. Архитектура решения с поддержкой U2F-аутентификации на базе токена JaCarta U2F

Основные компоненты системы аутентификации на базе токена JaCarta U2F:

Внешний вид токенов jacarta u2f

Рисунок 1. Внешний вид токена JaCarta U2F

Компактный пластиковый корпус токена JaCarta U2F в дизайне продуктовой линейки JaCarta и USB-разъем (оправка) отлиты из АБС-пластика и представляют собой единую конструкцию, что защищает электронный ключ от поломки в месте соединения разъема с печатной платой. Корпус токена защищен от необнаруживаемого вскрытия — попытка вскрытия приводит к видимым дефектам.

На лицевой стороне токена нанесен логотип JaCarta, на оборотной стороне — серийный номер. На торце корпуса расположена физическая кнопка, используемая для подтверждения присутствия пользователя за компьютером. Токен имеет светодиодный индикатор красного цвета, отражающий различные режимы работы.

В спецификации на токен JaCarta U2F заявлена следующая ресурсоемкость:

  • не менее 5 000 циклов подключений/отключений к разъему USB;
  • не менее 50 000 нажатий кнопки.

Возможности применения u2f ключей для цифровой подписи

Кроме непосредственно аутентификации, можно ли найти другие способы применения U2F ключей ?

Детали, представляющие интерес


Первое — это то, что устройство не хранит

service_private_key

для каждого сервиса: вместо этого, оно выводит

service_private_key

каждый раз используя HMAC-SHA256. Это очень важно для нас: очевидно, если бы каждое устройство хранило бы уникальные ключи отдельно для каждого сервиса, то только это устройство могло бы осуществлять аутентификацию впоследствии.

Это, между прочем, не является требованием U2F: U2F не указывает, как именно ключи должны храниться, и некоторые ранние реализации U2F, действительно, хранили ключи для каждого сервиса в отдельности. Этот подход обладает тем недостатком, что количество сервисов, для которых устройство может быть использовано, ограничено. Деривация service_private_key устраняет этот недостаток.

И второе — устройство имеет counter, чтобы предотвратить клонирование.

На первый взгляд, может показаться, что этот counter не позволяет нам реализовать обсуждаемую бэкап-стратегию (как минимум, мне так казалось, когда я пытался найти решение), однако на самом деле, он только помогает нам! Сейчас объясню.

Замечание насчет counter

Внимательный читатель может заметить, что имеется следующая проблема безопасности: что если злоумышленник получает доступ к основному токену и как-либо инициирует 2 000 000 000 аутентификаций? Тогда он получает доступ к сервису даже после того, как бэкап-токен был использован на этом сервисе.

К счастью, эта проблема имеет простое решение. В любом случае, счетчик должен быть реализован аппаратно (предположительно, на некотором криптопроцессоре), и для безопасной реализации этот аппаратный счетчик должен иметь диапазон меньше, чем 32 бита. Например, на ATECC508A счетчики могут считать только до 2097151, так что, устанавливая константу, добавляемую к счетчику, в любое значение большее чем максимальное значение счетчика, мы можем быть уверены, что основной токен никогда не сможет досчитать до счетчика в бэкап-токене.

Для пояснения: допустим, что на нашем U2F-токене используется ATECC508A, и обозначим счетчик внутри ATECC508A как hw_counter. Тогда:

  • В основном токене, мы используем для вычислений: hw_counter;
  • В бэкап-токене, мы используем для вычислений: hw_counter 2000000000.

Обратите внимание, что мы не модифицируем реальный

hw_counter

внутри криптопроцессора; он по-прежнему будет считать от 0 до 2097151. Вместо этого, каждый раз когда нам нужно получить значение счетчика, мы считываем

hw_counter

из ATECC508A, потом добавляем нашу константу, и возвращаем (для дальнейших вычислений для U2F).

Таким образом, диапазон значений счетчика в основном токене будет [0, 2097151], тогда как диапазон значений счетчика в бэкап-токене будет [2000000000, 2002097151]. Тот факт, что эти диапазоны не пересекаются, обеспечивает аннулирование основного токена при использовании бэкапа (если сервис использует counter; основные сервисы, которые я проверил, используют его).

Исследования ключей защиты

Есть все основания полагать что разработка U2F была инициирована инженерами Google и проводилась в сотрудничестве с представителями других компаний работающих в области Информационной Безопасности. В своей публикации «Ключи Защиты: Практическая криптография как второй фактор » [1] они проводят обзор и сравнение технологии Одноразовых Кодов OATH OTP с смарт-картами, сертификатами, RFID картами и даже смартфонами в качестве средства аутентификации.

Описание некого «Ключа Защиты» (это и есть U2F) предлагается как решение проблем возникающих при использовании выше упомянутых средств аутентификации. В работе передан довольно интересный опыт который компания  Google получила, используя одноразовые пароли (Google Authenticator) , как второй фактор доступа.

Исследование затронуло несколько лет и более чем сотню сотрудников внутри компании. Только в данной публикации нам удалось увидеть пример криптографического протокола который вероятно U2F использует для шифрования данных, выполненного на основе алгоритма шифрования 3DES в режиме двух ключей.

U2F означает (universal second factor) универсальный второй фактор. Это устройство которое должно служить вторым фактором в протоколах или реализациях систем двух-факторной аутентификации с участием человека. Например в дополнение к паролю, информационная система также проверит что пользователь обладает данным экземпляром U2F устройства.

Читайте также:  Public Key Cryptography: осваиваем открытые ключи на практике — «Хакер»

Криптографический функционал U2F устройства

Вкратце : U2F Имеет в памяти ключ шифрования неизвестной длины и качества. Шифрует им при помощи неизвестного алгоритма Секретный ключ из пары ECDSA , которую сам умеет предварительно генерирует в памяти. Выдает наружу этот зашифрованный ключ а также публичный ключ в открытом виде.

Для детального описания, сначала необходимо перечислить какие данные изначально записаны в памяти U2F Ключе :

  • Сертификат производителя, который содержит Публичный ключ который служит для цифровой подписи ECDSA (Цифровая Подпись на базе Эллиптических Кривых) в шаге 2. при регистрации ключа.
    — Хранит в себе секретный ключ который также используется в шаге 2.
  • Скорее всего ключ хранятся в защищенной ПЗУ памяти, и их невозможно удалить или изменить через APDU команды. Защита секретного ключа полностью отдана на реализацию производителя. Устройство никогда не «выдаст» секретный ключ или не позволит его изменить.

Сертификат производителя ключа дает возможность проверить кем устройство было произведено. Для взаимодействия с ключем существует ряд APDU (Application Data Unit) команд которые заставляют устройство выполнить ряд операций.

Перечислим фактический функционал U2F устройства в стандарте v.1 :

  1. Регистрирует Систему Аутентификации (СА)
    Вкратце: Устройство внутри себя генерирует пару ключей ECDSA, шифрует секретный ключ (используя свой Секрет и Параметр СА) и все это подпись  свой сертификат возвращает клиенту.
    Система аутентификации должна сохранить: Параметр, Публичный Ключ и Зашифрованный Секретный Ключ (Key Handle).
    Операция требует участия пользователя — необходимо дотронуться до корпуса устройства или нажать на кнопку.
    — В данной операции также участвует параметр Challenge чтобы задействовать принцип «запрос-ответ».
    — Устройство использует внутренний генератор случайных чисел, поэтому никогда не вернет одни и те же Ключи при регистрации даже если все входные данные одинаковые;
    Заметим: что протокол шифрования секретного ключа выбирает (а возможно и проектирует) и реализует производитель устройства, в стандарте этого нет. Инженеры Google в своей работе показали на примере как это можно сделать, используя 3DES с 2мя ключами. Мы полагаем что сейчас 90% устройств используют 3DES и протокол предложенный Google для шифрования Секретного Ключа.
    На данной иллюстрации показа Функция STORE — задача которой зашифровать Секретный Ключ из пары ECDSA (это будет KeyHandle) , и функция RETRIEVE — задача которой расшифровать KeyHandle чтобы получить Секретный Ключ из пары ECDSA Секретный Ключ.
    Физические U2F ключи безопасности - Что это? | Портал о системах видеонаблюдения и безопасности
  2. Производит проверку Зашифрованного Секретного Ключа ECDSA и Параметра системы.
    Данная операция не требует участия пользователя. U2F Ключ попробует расшифровать Зашифрованный Секретный Ключ (KeyHandle) используя свой внутренний Секрет и Параметр СА.
    Благодаря этой операции Системма Аутентификации может определить какому пользователю принадлежит ключ.
  3. Производит цифровую подпись «Вопроса» (challenge)
    Эта функция также выполнит проверку подлинности Зашифрованного Секретного Ключа ECDSA (шаг 3) .
    Если все верно, устройство продолжит обработку запроса и вернет цифровую подпись дайджеста: «Вопрос», Параметр СА, Счетчик. Это позволит Системе проверить достоверность использования ключа именно в данный момент времени. Благодаря дополнительным параметрам которые участвуют в подписи, система также может проверить что Подпись создана данным ключом именно для нее в присутствии пользователя.
  4. Ведет счетчик всех созданных Подписей.
    Данное значение возвращается всегда в шаге 4 и участвует также в подписи. Может быть использован системой СА для дополнительных проверок. Например если новое значение которое вернул ключ меньше чем то что помнит система, возможно пользователь восстановил утерянный токен либо это копия устройства. Возможно это средство защиты от программных реализаций U2F которые вскоре появятся в сети. Благодаря этому счетчику созданная подпись всегда будет другой, даже если все входные данные одинаковые;  

Мы скрыли некоторые детали для простоты изложения. Заметим, что Зашифрованный Секретный Ключ ECDSA (Key handle) и параметр Системы аутентификации возможно должен рассматриваться инженерами как секретные данные. В случае их компрометации становиться возможным выполнять ряд атак,  а в случае утери идентифицировать или аутентифицировать устройство становиться невозможным.

Хотим отметить неизвестные и критические места в реализации U2F устройства:

  • Качество и защита секретного ключа сертификата производителя;
  • Генератор случайных чисел;
  • Протокол генерации пары публичных ключей может быть неизвестным для конкретной модели устройств.
  • Алгоритм и протокол шифрования секретного ключа также может быть неизвестным. А также роль Параметра системы аутентификации в этом протоколе.
  • Принцип работы «датчика присутствия человека»

На наш взгляд, если датчик присутствия возможно обмануть программным либо физическим способом и заставить устройство генерировать и подписывать данные очень быстро, это даст возможность проводить анализ протокола защиты конкретного устройства.

В стандарте U2F явно сказано что криптографический протокол выбирает и реализует сам производитель устройства. Например известный производитель u2f устройств компания Юбико ограничилась лишь публикацией примерной схемы своей реализации протокола, но не опубликовала детали, алгоритм шифрования секретного ключа и исходный код этого протокола.

Во всяком случае нам это пока не удалось выяснить. И позиция компании такова что открывать принцип работы и особенности защиты устройства они не будут. Напомним что в 2021, благодаря сообществу в ключе Yubikey была обнаружена некритичная уязвимость [2]. Об этих особенностях упоминается также в данном исследовании U2F ключей.

Как работает рутокен u2f

Наличие второго фактора USB токена Рутокен U2F, делает кражу пароля бессмысленной, т.к. для доступа к аккаунту помимо пароля нужно предъявить и сам токен.

Чтобы защитить Рутокен U2F от клонирования, в токене предусмотрен встроенный счетчик операций регистраций и входов.

Для начала использования токена необходимо привязать его к учетной записи. В процессе регистрации токена, он с помощью браузера общается с сайтом, отправляя на сервер открытый ключ и подписывая всю «переписку» своим закрытым ключом. Сайт сохраняет открытый ключ и связывая его с конкретной учетной записью.

Киберпреступники не спят

Киберпреступники изобретают все новые способы обмана для кражи конфиденциальной информации о пользователях интернета. Наиболее желательными являются входные данные в систему электронных банковских услуг, но кража личных данных также используется для вымогательства денег у жертвы и его друзей.

Поэтому включение двухэтапной проверки чрезвычайно важно и ее использование может быть упрощено с помощью физических ключей безопасности U2F. Это, конечно, не освобождает от необходимости использовать надежные пароли, но благодаря такому решению, нет необходимости создавать и перезаписывать коды, подтверждающие личность пользователей.

Ключ keydo fido u2f

Ключ Keydo Fido U2F — это компактное устройство для более эффективной защиты данных. Просто используйте ключ Keydo при каждом входе на сайт. Двухэтапный процесс верификации работает значительно быстрее, чем ввод одноразового кода доступа, а сам ключ не требует подключения к интернету. Это позволит защитить пользователя от наиболее распространенного вида атак, например, фишинг.

Краткий обзор протокола u2f

Прежде чем мы можем говорить о реализации, мы должны на определенном уровне понимать, как работает U2F. Большинство производителей реализуют его следующим образом (не все из нижеприведенного присутствует в стандарте; некоторые вещи являются деталями реализаций, но большинство существующих реализаций, насколько мне известно, работает именно так):

В U2F-токене запрограммирован device_secret, вместе с 32-битным counter, который может быть только инкрементирован. Когда мы регистрируем U2F-токен на каком-либо сервисе, происходит следующее:

  • Браузер отправляет U2F-устройству AppID (фактически, доменное имя);
  • Устройство генерирует случайное число (nonce), объединяет его с его с AppID, пропускает все это через HMAC-SHA256 используя device_secret в качестве ключа, и результирующий хеш становится приватным ключом для этого конкретного сервиса: service_private_key;
  • Из service_private_key, генерируется публичный ключ service_public_key;
  • Устройство берет AppID снова, объединяет его с service_private_key, и снова пропускает через HMAC-SHA256 используя device_secret в качестве ключа. Результат (MAC), вместе с nonce который был сгенерирован ранее, становится key_handle;
  • Устройство отправляет key_handle и service_public_key обратно браузеру, и браузер передает сервису, который сохраняет эти данные для будущих аутентификаций.


Последующая аутентификация проходит следующим образом:

  • Сервис генерирует challenge (случайно сгенерированные данные) и отправляет их браузеру вместе с key_handle (который состоит из nonce и MAC). Браузер передает все это устройству, вместе с AppID (т.е. доменным именем);
  • Устройство, имея nonce и AppID, генерирует service_private_key тем же самым образом, которым он был сгенерирован при регистрации;
  • Устройство генерирует MAC тем же самым образом как и при регистрации, и сравнивая его с MAC полученным от браузера, удостоверяется что nonce не подменен, и следовательно, service_private_key достоверен;
  • Устройство инкрементирует counter;
  • Устройство подписывает challenge, AppID и counter с помощью service_private_key, и отправляет результирующую подпись (signature) и counter браузеру, который передает эти данные далее на сервис;
  • Сервис проверяет signature с помощью имеющегося у него после регистрации service_public_key. Также, большинство сервисов проверяют, что counter больше, чем предыдущее значение (если это не первая аутентификация). Цель этой проверки — сделать недоступным клонирование U2F-устройств. В итоге, если signature совпадает и counter больше, чем предыдущее значение, аутентификация считается успешно законченной, и сервис сохраняет новое значение counter.

Теперь давайте обозначим детали, которые имеют прямое отношение к дискуссии.

Читайте также:  Доверенность на получение сертификата — Удостоверяющий центр СКБ Контур

Можно ли использовать u2f для управления целостностью конфигурации операционной системы? или анти-вирусах (configuration, change management).

Да. Это довольно новая идея и она напоминает принцип работы аппаратного модуля TPM. Идея состоит в том чтобы ОС или АнтиВирус просил пользователя Подписать U2F Ключем любое изменение конфигурации ОС и ПО. U2F позволит реализовать цифровую подпись с дву-факторную аутентификацией, каждый новый Исполняемый модульУстанавливаемый пакет, файл настроек будет подписан лично Администратором.

В этом случае АнтиВирус сможет со 100% вероятностью определять уровень доверия каждому приложению и определять несанкционированное создание на диске исполняемых модулей или изменение конфигурации. Для реализации этой идеи U2F ключ должен позволяет генерировать подписи пока пользователь держит U2F Кнопку в нажатом состоянии, что позволит подписать много модулей за 1 раз.

Можно ли использовать u2f для хранение секретных или генерации некого секретного ключа который затем можно использовать для шифрования ?

Нет. Функция U2F регистрации всегда возвращает новые данные, для одних и тех же же входных данных. При генерации ключей используется генератор случайных чисел. А при подписи, в дайджесте используется значение счетчика .

Можно ли использовать u2f для хранения пары ключей от крипто-валютных кошельков?

Да, но необходимо изменить протокол дайджестасообщений в Крипто Кошельке под U2F дайджест.Все программы крипто-кошельки например Bitcoin — это ключевая пара ECDSA.  Где секретный ключ является крайне критическим параметром. Потеряв его теряеш все биткойны и наоборот Подгядев его, злоумышленник фактически владеет всеми твоими биткойнами.

Хотя сам Секретный ключ используется только если была обнаружен очередной блок (вы добыли биткойн еденицу) либо если вы покупаете продаете свои биткойны. Следовательно имеет смысл его хранить в защищенномзашифрованном месте и использовать только когда необходимо.

В этом случае также можно использовать PKCS#11 ключ аппаратный PIN код для хранения секретного ключа биткойн-кошелька в памяти устройства. В случае с U2F сейчас это сделать невозможно поскольку Дайджест сообщения который он использует для подписи не совпадает с Дайджестом КриптоКошельков.

Можно ли использовать u2f ключ для цифровой подписи документов и почты?

Да. U2F ключ способен подписать произвольный дайджест. Эта идея довольно легко реализуема посредством виртуальных смарт карт или создания специального Criptographic Service Provider модуля который будет подписывать при помощи U2F ключа вместо того чтобы использовать секретный ключ из сертификата или механизм PKCS. Преимущества U2F перед классическим подходом основанном на сертификатах и PKI :

  • Отсутствие секретных ключей. В терминах U2F отсутствует понятие «секрета».
  • Использование Одного U2F ключа в разных Периметрах Доверия (компаниях, сервисах и т.д). 
    Например один ключа можно использовать для Аутентификации в почту, для подписи в разных системах, для доступа в ПК.
  • Программный механизм истечения срока годности ключа. Это позволяет атрибут «срок годности» отключить или изменять на ходу.
  • Вместо корневого Центра Сертификации можно использовать один или несколько U2F ключей, подпись которых будет использована при генерации начальных параметров.
  • Поддержка двух-факторной аутентификации для цифровой подписи.
    Если знать PIN код смарт-карты или токена, то можно генерировать подпись программным путем. Подтверждение оператора не требуется, и далее уже невозможно даже доказать что подпись была сделана с санкции Оператора или программно.
    В случае с U2F ключом — для подписи обязательно присутствие человека, даже если ключ подключен к ПК в данный момент.

Не-u2f метод в качестве бэкапа

OTP:

  • Использовать OTP в качестве бэкапа — это лучше, чем использовать его как основной метод 2FA, но факт наличия OTP так или иначе открывает дополнительный вектор атаки;
  • Телефоны ломаются, теряются и крадутся, и если после его утери есть вероятность, что он окажется у посторонних лиц, то нужно вручную отозвать этот бэкап на всех аккаунтах;
  • Я всегда ношу телефон и U2F токен с собой, так что, опять же, подобный метод бэкапа далек от идеала: вероятность утери сразу и того, и другого, значительно выше, чем если бы бэкап хранился отдельно. Но этот пункт можно немного компенсировать, используя, например, Authy, который хранит зашифрованный бэкап у себя на сервере;
  • Неуниверсальный метод: к сожалению, есть достаточное количество сервисов, предлагающих только кастомные приложения, и не поддерживающих стандартный TOTP.

Коды восстановления:

  • Коды восстановления нужно хранить в безопасном месте. Опять же, это «безопасное место» будет, скорее всего, моим домом, с почти такими же проблемами, как и у отдельного U2F токена;
  • Опять-таки, неуниверсальный метод: у каждого сервиса свой подход к бэкапу


Так что, подводя итоги, все эти методы неуниверсальны, обременительны и не слишком безопасны.

Независимый u2f токен

Это означает, что каждый раз при регистрации на каком-нибудь новом сервисе, мне нужно добавить оба моих токена. Это обстоятельство порождает ряд проблем:

  • Бэкап-токен должен быть довольно легкодоступным. Несмотря на то, что я не буду носить его с собой на связке ключей, я должен иметь возможность быстро до него добраться, так что я вряд ли смогу придумать что-то лучше, чем держать его у себя дома. Насколько это реально безопасно, даже если используется сейф — можно долго говорить;
  • Когда я вынужден регистрироваться на каком-нибудь сервисе находясь вне дома, я не могу добавить бэкап-токен. Так что нужно постараться запомнить, что нужно добавить его позднее, и пока это не произошло, бэкапа нет. В худшем случае, я могу и вообще забыть про него;
  • Когда я дома, оба моих токена находятся в одном и том же месте. Такой метод бэкапа далек от идеала: оба токена могут оказаться недоступны вследствие одного происшествия (быть уничтожены или украдены) ;
  • Тот факт, что бэкап-токен хранится дома, совершенно очевиден. Если кто-то действительно хочет добраться до моего токена, он уже знает, где его искать;
  • Неуниверсальный метод: не все сервисы позволяют добавить более одного ключа в аккаунт.

На мой взгляд, эта «образцовая практика» не очень надежна, и довольно обременительна. Давайте посмотрим на другую распространенную практику.

Оптимальный метод бэкапа

Теперь, после того как я достаточно раскритиковал существующее положение дел, я, наконец, скажу, что же я на самом деле хочу. Я действительно хочу иметь два U2F токена: основной и бэкапный, но они должны быть настроены определенным образом:

  • Когда я регистрирую основной токен на каком-либо устройстве, бэкап-токен автоматически становится рабочим для этого сервиса;
  • Как только я использую бэкап-токен на каком-либо сервисе, основной токен оказывается недействительным для этого сервиса.


Прежде, чем мы обсудим техническую возможность этого в рамках U2F, я объясню почему это здорово, и как я это использую.

Популярные методы бэкапа

На сегодняшний день, образцовая практика — держать второй независимый U2F токен для бэкапа; этот токен должен быть добавлен вручную на каждый сервис и храниться в «безопасном» месте. Другая общепринятая практика — использовать не-U2F метод в качестве бэкапа (OTP, коды восстановления). Честно говоря, оба этих метода оставляют желать лучшего.

Предупреждение

Несмотря на то, что эта бэкап-стратегия крута, я не настолько уверен в ее конкретной реализации, посредством u2f-zero или solokey. Этот путь — единственный способ получить желаемое, так что этим путем я и пошел; но если предположить, что злоумышленник получает физический доступ к U2F-устройству, я не уверен, что взлом устройства (т.е. получение

device_secret

из него) будет настолько же сложным, каким бы он был в случае Yubikey или других основных производителей. Авторы solokey заявляют, что «уровень безопасности такой же, как в современном автомобильном ключе», но я не проводил экспертиз чтобы это подтвердить.

Тем не менее, честно говоря, я не очень об этом беспокоюсь. Если злоумышленник просто крадет токен без намерения его вернуть, то тогда сложность его взлома не играет роли, т.к. злоумышленник может просто использовать этот токен для доступа в аккаунт и, например, просто отозвать этот токен и добавить другой. Однако, для этого я должен иметь и другие серьезные проблемы безопасности, т.к. U2F-токен — это только второй фактор.

Так что, единственный сценарий, при котором solokey может быть менее безопасным, чем что-то другое — это когда злоумышленник пытается получить доступ к устройству в течение краткого промежутка времени, получить device_secret из него, и вернуть устройство обратно, незаметно для меня.

Принимая во внимание все факторы, я считаю, что для меня лично иметь надежный бэкап — это гораздо более важно, чем иметь сверхбезопасную аппаратную реализацию U2F-устройства. Вероятность проблем с такой безопасной реализацией и отсутствием хорошего бэкапа выше, чем вероятность проблем с u2f-zero (solokey) и бэкапом.

Работа с jacarta u2f

Для корректной работы JaCarta U2F пользователю требуется один из веб-браузеров:

  • Google Chrome — версия 41 или выше;
  • Opera — версия 40 и выше,
  • FireFox (поддержка обеспечивается за счет дополнительных плагинов работы с FIDO U2F).  
Читайте также:  Сигнализации с ключами в Москве купить недорого в интернет магазине с доставкой | Compumir

Как уже было сказано выше, JaCarta U2F поддерживает операционные системы семейств Microsoft Windows, Linux, macOS для персональных компьютеров. На мобильных устройствах поддержка U2F реализована либо в самой мобильной платформе, либо через специальное приложение, работающее с ключом FIDO U2F.

Среди популярных онлайн-сервисов, поддерживающих протокол FIDO U2F, можно выделить следующие:

Компания «Аладдин Р.Д.» добавила поддержку протокола FIDO U2F в последнюю версию сервера аутентификации JaCarta Authentication Server 1.6. Данный продукт зарегистрирован в реестре российских программ для ЭВМ и БД (№ 2128) и активно внедряется в сети корпоративных заказчиков в России.

Регистрация токена jacarta u2f

Для использования токена JaCarta U2F в качестве второго фактора в процедуре аутентификации необходимо зарегистрировать токен на онлайн-сервисах. Сервисы Google, Dropbox и GitHub требуют включить в качестве второго фактора аутентификации одноразовые пароли.

Таким образом, регистрация JaCarta U2F происходит после настройки получения одноразовых паролей для доступа в учетную запись. Одноразовые пароли могут генерироваться приложением на мобильном устройстве пользователя или присылаться в SMS-сообщениях. В качестве генераторов одноразовых паролей используются:

  • Google Authenticator (Android, iOS, BlackBerry OS);
  • Duo Mobile (Android, iOS);
  • Amazon AWS MFA (Android);
  • Authenticator (Windows Phone 7).

Рисунок 3. Настройка двухфакторной аутентификации для сервисов Google

Рисунок 4. Настройка двухфакторной аутентификации пользователя сервиса Dropbox

При регистрации токена JaCarta U2F от пользователя требуется не только подключить его к USB-порту, но и инициализировать процесс регистрации нажатием кнопки на корпусе токена.

Рисунок 5. Сервис Google ожидает действий пользователя

Рисунок 6. Инициализация токена JaCarta U2F в сервисе Dropbox

В случае успешной регистрации токена изменится список зарегистрированных электронных ключей пользователя.

Рисунок 7. Список зарегистрированных электронных ключей пользователя Google

Рисунок 8. Электронный ключ пользователя Dropbox успешно добавлен

Сравнение u2f с одноразовыми паролями oath totp (google authenticator) :

  • При регистрации (конфигурации) U2F ключа нет необходимости оперировать с его секретным ключом  , как в случае с TOTP когда необходимо передать СотрудникуПользователю секретный ключ для того чтобы установить его в смартфон с Google Authenticator). Далее необходимо усиленно строго хранить секретный ключ на стороне сервера.
  • Защита от несанкционированных дубликатов U2F ключей.
    Наличие дубликата TOTP конфигурации невозможно определить. Можно настроить два телефона с Google Authenticator и оба будут генерировать верные Коды и их нельзя отличить. Даже в случае с HOTP когда фигурирует счетчик, нельзя с уверенностью утверждать что это «скопированный» счетчик а не результат того что Пользователь многократно сам заставил устройство выполнить генерацию Кода без дальнейшего его предоставления системе аутентификации.
  • Защита от повторного использования Одноразового Кода либо использования «Старого» Кода.
    В системах аутентификации при помощи Одноразовых паролей теоретически возможно воссоздать такую ситуацию когда ранее сгенерированный Код (использованный или не использованный) будет принят системой. Например в H/TOTP конфигурации возможно имитировать атаку с десинхронизацией времени когда Высокопоставленный сотрудник звонитпишет Администратору и говорит например так: «я в командировке и мой Одноразовый пароль не работает, видимо потому что у меня сейчас -2 часа по сравнению с офисом. Сделай что нибудь, мне нужен доступ». Администратор в этом случае делает синхронизацию T/TOTP параметров в программном обеспечении, что в свою очередь, в зависимости от качества реализации ПО (системмы аутентификации) может привести к полному збросу истории всех ранее использованных кодов.
    В этом случае система при первой аутентификации для данного Пользователя, выполнит синхронизацию часов (т.е. найдет временной сдвиг, путем поиска всех возможных Одноразовых Паролей на временном интервале в несколько часов от локального времени). В этот момент она обнаружит что предоставленный Код соответствует временному сдвигу в 5 часов (тот Код который на самом деле был уже использован 5 часов назад и перехвачен либо подсмотрен на экране смартфона, но не использован). И повторим, что в зависимости от реализации, система может счесть такую ситуацию нормальной и в итоге Принять такой Код и одобрить аутентификацию.
    В случае с U2F это невозможно благодаря механизму «запрос-ответ»
  • Возможна Офлайн аутентификация.
    Поскольку мы планируем использовать U2F для аутентификации в сетевой инфраструктуре Windows/Linux, возможна ситуация когда компьютерноутбук не подключен к сети предприятия и необходимо выполнить аутентификацию ключа без участия домена. В случае с T-OTP программа Rohos Logon Key может быть настроена чтобы хранить настройки TOTP  (включая секретный ключ) также на рабочей станции, что конечно понижает уровень безопасности и вероятность клонирования TOTP ключа. В случае с U2F хранить на рабочей станции необходимо только данные о настройке ключа которые не являются столь секретными.

Технические характеристики рутокен u2f

Рутокен U2F поддерживает следующие: 

  • Google Chrome (версия 38 )
  • Firefox (версия 57 )
  • Opera (40 )
  • Microsoft Edge

Платформы:

Тип криптографического ключа — ECC P256

Интерфейс подключения — USB

Токен epass fido u2f nfc usb-a k9 купить у дистрибьютора ооо ‘датавэй секьюрити’, 7 (495) 268-01-26 | цена | россия, москва

Токен ePass FIDO U2F NFC сертифицированный FIDO Alliance U2F-аутентификатор, который обеспечивает безопасную, фишинг-устойчивую схему двухфакторной аутентификации.
ePass FIDO U2F NFC поддерживается приложениями: Google, GMail, Google Drive, Facebook, Twitter, Dropbox, Github, GitLab, Salesforce, Bitbucket, Dashlane, Duo, Digientity, BITFINEX, FastMail, Gandi.net, Keeper, Sentry и многими другими, а также может интегрироваться с серверами аутентификации, использующих алгоритм HOTP.
Помимо поддержки OATH-HOTP и GIDS для осуществления двухфакторной аутентификации, токен имеет встроенный высокопроизводительный элемент безопасности NXP, который кроме генерирования случайных и надежных пар ключей для аутентификации FIDO U2F, позволяет использовать токен как Java-платформу для предоставления доступа к другим приложениям, а также защищать личную информацию пользователя от различных видов угроз безопасности.

Функционал:

Фактическая реализация

Ни один из производителей U2F-токенов, о которых я знаю, не поддерживает требуемой кастомизации на сегодняшний день. Но к счастью, существует open-source реализация U2F-токена:

Я писал свою оригинальную статью (на английском) год назад, и эта часть несколько устарела: тогда SoloKeys был на стадии прототипирования, а я использовал предыдущую итерацию проекта: u2f-zero. Поэтому переводить эту часть я сейчас не буду, поскольку единственный способ получить u2f-zero устройство — это спаять его самостоятельно, и заниматься этим вряд ли целесообразно (хотя на гитхабе есть инструкции).

Тем не менее, все подробности необходимой модификaции u2f-zero приведены в оригинальной статье.

Когда дойдут руки до solokeys, я напишу и инструкцию по его модификации.

Так или иначе, это — единственный известный мне на сегодня способ получить рабочий U2F-токен с надежным бэкапом. Проверка нескольких сервисов (как минимум google и github) показала, что он работает: зарегистрировав основной токен на сервисе, мы можем также использовать бэкап, и после первого использования бэкапа, основной токен перестает работать. Awwwwwww. <3

Функциональные возможности

Токен JaCarta U2F поддерживает аутентификацию пользователя по стандарту FIDO U2F, обладая рядом особенностей, отличающих его от альтернативных технологий аутентификации:

Выводы

Стандарт FIDO U2F активно поддерживается крупнейшими мировыми ИТ-компаниями, что делает актуальным его применение для российских пользователей. Отечественная компания «Аладдин Р. Д.» разработала продукт, отвечающий всем требованиям стандарта FIDO U2F.

Токены JaCarta U2F отличаются своей низкой стоимостью и отсутствием требований к сложной системе аутентификации и дополнительных средств администрирования — пользователь сам настраивает и контролирует использование своего электронного ключа. Токены U2F кроссплатформенны, возможность их использования на различных онлайн-ресурсах ограничивается лишь объемом встроенной памяти.

Преимущества:

  • Пользователь не раскрывает свои персональные данные (например, номер телефона в случае аутентификации по одноразовым паролям).
  • Токен JaCarta U2F защищен от компрометации: в отличие от биометрических данных (например, отпечаток пальца) или SMS, его невозможно подделать.
  • Токен JaCarta U2F не зависит от дополнительных устройств (в случае использования одноразовых паролей пользователю необходимо мобильное устройство с установленным приложением и связь с сервером).
  • Токены JaCarta производятся в России и используют отечественное ПО (токены U2F шведской компании Yubico перестали поставляться на наш рынок в связи с санкциями).
  • Простота использования.
  • Поддержка сервера аутентификации JaCarta Authentication Server.

Ограничения:

  • Пользователю может быть затруднительно работать с данной моделью на мобильных устройствах (требуются специальные переходники).
  • Среди российских онлайн-сервисов не распространена поддержка протокола FIDO U2F.

Заключение

Рассмотренная стратегия бэкапа выигрывает у альтернатив на всех измерениях: она универсальна, более безопасна и более надежна, чем любые другие способы.

Я буду рад, если хотя бы один из основных производителей реализует это в своих продуктах, но уверенности пока нет. Один парень из поддержки Yubico, James A., даже сказал мне, что реализовать бэкап так, как мне нужно, «is not possible with the way U2F is designed», и после того, как я изложил детали реализации, он просто перестал отвечать.

К счастью, это оказалось не настолько невозможно, насколько считает Yubico.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector