Обзор возможностей ключей защиты FIDO U2F. Принцип работы и варианты использования

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

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

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

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

Вкратце : U2F Имеет в памяти ключ шифрования неизвестной длины и качества. Шифрует им при помощи неизвестного алгоритма Секретный ключ из пары ECDSA , которую сам умеет предварительно генерирует в памяти. Выдает наружу этот зашифрованный ключ а также публичный ключ в открытом виде. Далее умеет принять обратно эти данные, расшифровать Секретный ключ 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 Секретный Ключ.
  2. Производит проверку Зашифрованного Секретного Ключа ECDSA и Параметра системы.
    Данная операция не требует участия пользователя. U2F Ключ попробует расшифровать Зашифрованный Секретный Ключ (KeyHandle) используя свой внутренний Секрет и Параметр СА.
    Благодаря этой операции Системма Аутентификации может определить какому пользователю принадлежит ключ.
  3. Производит цифровую подпись «Вопроса» (challenge)
    Эта функция также выполнит проверку подлинности Зашифрованного Секретного Ключа ECDSA (шаг 3) .
    Если все верно, устройство продолжит обработку запроса и вернет цифровую подпись дайджеста: «Вопрос», Параметр СА, Счетчик. Это позволит Системе проверить достоверность использования ключа именно в данный момент времени. Благодаря дополнительным параметрам которые участвуют в подписи, система также может проверить что Подпись создана данным ключом именно для нее в присутствии пользователя.
  4. Ведет счетчик всех созданных Подписей.
    Данное значение возвращается всегда в шаге 4 и участвует также в подписи. Может быть использован системой СА для дополнительных проверок. Например если новое значение которое вернул ключ меньше чем то что помнит система, возможно пользователь восстановил утерянный токен либо это копия устройства. Возможно это средство защиты от программных реализаций U2F которые вскоре появятся в сети. Благодаря этому счетчику созданная подпись всегда будет другой, даже если все входные данные одинаковые;  

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

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

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

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

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

Сравнение 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 c PKCS#11 токенами

  • В U2F Отсутствует обязательный ПИН код Пользователя и Администратора для защиты доступа и конфигурации.
  • U2F Выполняет действие для аутентификации только с согласия пользователя (прикосновение к устройству). Постороннее программное обеспечение не сможет выполнять с устройством никакие операции.
    В случае с PKCS#11 любая программа, без ведома пользователя может заблокировать PIN код токена например, либо считать данные с ключа используя один из заводских ПИН кодов администратора или пользователя, либо перехватить ПИН код (кейлоггер) и далее прочитать с токена все данные.
  • При потере U2F ключ может быть использован для аутентификации злоумышленником, что исключено в случае с PKCS#11 ключом и его PIN кодом.
  • При настройке U2F не требует установки драйверов и утилиты для форматирования\конфигурации устройства как в случчае с PKCS#11.
  • Протокол общения с U2F устройством напоминает APDU команды для смарт-карт. Для PKCS#11 необходимо использовать библиотеку производителя.
  • При использовании U2F устройства (ключа) возможно доказать факт аутентификации при помощи данного ключа, в данный момент времени. Но эта возможно должна быть реализована на стороне системы аутентификации. В случае с PKCS#11 ключом, такой возможности не предусмотрено. Ключ возвращает Сертификат или Блок данных, но они часто не привязаны к серийному номеру ключа.

Возможности применения U2F ключей защиты

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

  • Хранение секретных данных или получение некого секретного ключа который затем можно использовать для шифрования ?
    Нет.
    Функция U2F регистрации всегда возвращает новые данные, для одних и тех же же входных данных. При генерации ключей используется генератор случайных чисел. А при подписи, в дайджесте используется значение счетчика .
  • Хранение пары ключей от крипто-валютных кошельков?
    Да, но необходимо изменить протокол дайджеста\сообщений в КриптоКошелке под U2F дайджест.
    Все программы крипто-кошельки например Bitcoin — это ключевая пара ECDSA.  Где секретный ключ является крайне критическим параметром. Потеряв его теряеш все биткойны и наоборот Подгядев его, злоумышленник фактически владеет всеми твоими биткойнами.  Хотя сам Секретный ключ используется только если была обнаружен очередной блок (вы добыли биткойн еденицу) либо если вы покупаете \ продаете свои биткойны. Следовательно имеет смысл его хранить в защищенном\зашифрованном месте и использовать только когда необходимо. В этом случае также можно использовать PKCS#11 ключ + аппаратный PIN код для хранения секретного ключа биткойн-кошелька в памяти устройства. В случае с U2F сейчас это сделать невозможно поскольку Дайджест сообщения который он использует для подписи не совпадает с Дайджестом КриптоКошельков. Но если это исправить то U2F ключ станет самым доступным и безопасным устройством для защиты Bitcoin и других крипто-валют.
  • Ключ для подтверждения Доверия в Операционной Системе или Анти-вирусах. Trust Provider Key.
    Да.
    Это довольно новая идея и она напоминает принцип работы аппаратного модуля TPM. Идея состоит в том чтобы ОС или АнтиВирус просил пользователя Подписать U2F Ключем каждый новый Исполняемый модуль\Устанавливаемый пакет.
    В этом случае АнтиВирус сможет со 100% вероятностью определять уровень доверия каждому приложению и определять несанкционированное создание на диске исполняемых модулей. Для реализации этой идеи U2F ключ должен позволяет генерировать подписи пока пользователь держит U2F Кнопку в нажатом состоянии, что позволит подписать много модулей за 1 раз.
  • Реализация непрерывной аутентификации в Индустриальных Системах (ICS/SCADA/SmartGrid)
    Да.
    В Индустриальных Системах вопросы Доверия и Аутентификации тесно связаны между собой, что требует реализации принципа непрерывной аутентификации. Реализация этого принципа методом Поведенческого Анализа (User Behavior Analysis / Biometrics) пока не увенчались большим успехом. А вот использование U2F Ключ для подтверждения Доверия и Аутентификации также оперирует обязательным присутствием человека и дает ряд преимуществ: 
    — отсутствие ложных срабатываний, -быстрое подтверждение операций, -возможность аудирования подтверждений, -применение принципа много-факторной аутентификации по отдельному каналу (out of band).

 

Источники:

[1] Google, Security Keys: Practical Cryptographic Second Factors for the Modern Web
https://research.google.com/pubs/pub45409.html

[2] Yubico, SecurityAdvisory 2015-04-14.
https://developers.yubico.com/ykneo-openpgp/SecurityAdvisory%202015-04-14.html