Юрий Аккерманн: «Один из фундаментальных принципов FIDO Alliance — обеспечение приватности»

    Интервью со старшим сертификационным инженером FIDO Alliance о беспарольной аутентификации


    Наши пользователи попросили нас реализовать двухфакторную аутентификацию через приложение Google. И недавно мы эту возможность им предоставили. Примерно в то же время консорциум FIDO Alliance опубликовал стандарты для беспарольной аутентификации на сайтах, в мобильных приложениях и веб-сервисах — WebAuthn и CTAP.

    Мы заинтересовались этой темой и подготовили материал на Хабре, в котором поговорили о методах, лежащих в основе новых протоколов.

    Затем, чтобы прояснить некоторые моменты, касающиеся тонкостей работы стандарта, мы пообщались с Юрием Аккерманном (herrjemand), старшим сертификационным инженером FIDO Alliance. Он ответил на несколько наших вопросов о прошлом, настоящем и будущем аутентификации FIDO. Представляем вашему вниманию текст интервью.


    / Flickr / zhrefch / PD

    Расскажите, пожалуйста, о своем бэкграунде и опыте работы в IT-сфере в целом. С чего начинали свою работу в отрасли?


    Я занимаюсь программированием с пятнадцати лет. После школы я поступил в университет, где изучал информатику и математику. На втором курсе стал интересоваться криптографией, вопросами ИБ и «наткнулся» на FIDO. Мне очень понравились их протоколы, и в итоге я написал U2F-библиотеку для Python Flask и сделал презентацию.

    Мою работу оценили в FIDO. При этом они как раз искали сертификационного инженера. В итоге я стал ответственным за техническую сертификацию.

    Как долго вы занимаетесь темами, связанными с аутентификацией в рамках FIDO? Какие задачи вы решали в процессе разработки нового стандарта?


    С FIDO протоколами я работаю уже три года — два из них в FIDO Alliance. Моя главная роль — техническая сертификация и автоматические инструменты для тестирования имплементаций на соответствие спецификациям. В мои обязанности входит разработка и поддержка самих инструментов, а также написание тестовых планов — списков тестов для проверки серверов, клиентов и аутентификаторов. Думаю, что написание тестового плана — это самый трудоемкий процесс, так как он требует понимания всех тонкостей протоколов и используемых в них стандартов.

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

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


    FIDO Alliance основали в 2013 году компании Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal и Validity, которые разработали UAF. Чуть позже к ним присоединились Google, Yubico и NXP — эти работали над предшественником U2F и подумали, что будет выгодно объединить силы, так как их идеи совпадали с идеями Альянса. Они стремились защитить интернет-пользователей от фишинга, решить проблемы удобства использования паролей, а также развивать доступность и безопасность биометрических технологий.

    Проводились ли какие-либо предварительные исследования, которые или укрепили намерение создать стандарт, или подтолкнули к его созданию? Если да, то какого рода данные вы анализировали?


    Члены альянса, такие как Google, Microsoft, Samsung, Yubico и другие, активно работают над созданием и продвижением стандартов. Они исследуют рынки, пытаясь понять, как FIDO может «вписаться» в различные экосистемы. В Google, например, провели исследование по миграции второго фактора c одноразовых паролей на U2F.

    Как родился протокол CTAP? Каким образом он связан с WebAuthn?


    FIDO состоит из трех частей: сервера, клиента (браузер) и аутентификатора. Сервер посылает вызов клиенту, клиент передает вызов аутентификатору, который его подписывает и возвращает клиенту, а тот — уже серверу.

    Для того чтобы сервер мог пользоваться аутентификацией FIDO, в клиентах есть WebAuthn JS API. С аутентификаторами клиент общается с помощью низкоуровневого протокола CTAP2 (Client-to-Authenticator Protocol 2). CTAP2 описывает CBOR-структуры запросов и транспорты, как, например, USB, NFC и BLE для общения с аутентификатором. Совокупность этих двух стандартов называют FIDO2.

    Одной из целей создания формата является защита от фишинга. Какие преимущества стоит выделить по сравнению с другими решениями?


    Если говорить о существующих решениях, то единственное, с чем можно сравнить FIDO, это клиентские сертификаты или TLS CCA (Client Certificate Authentication). FIDO и CCA — это фишинг-безопасные вызов-ответ протоколы на публичных ключах. Но у них есть существенные различия.

    CCA не защищены от атаки повтором. Они переиспользуют один сертификат на множестве сайтов, что способно привести к деанонимизации пользователя. В FIDO мы генерируем новую уникальную пару ключей на каждую регистрацию, чтобы сохранить приватность.

    Также у CCA есть проблема с хранением ключей, так как в большинстве случаев приватный ключ либо зашифрован в PKCS12, либо просто лежит в открытом виде. Таким образом, его без проблем может украсть даже непривилегированное приложение. В FIDO все ключи хранятся в безопасности, например, в одностороннем хранилище SecureEnclave. Восстановить ключи из хранилищ подобного типа очень трудно.

    У CCA наблюдаются трудности с правильной имплементацией на серверной стороне, так как полная поддержка CCA оставляет желать лучшего. А из-за сложностей работы с TLS, разработчики делают множество ошибок. В FIDO нужна только поддержка самой базисной криптографии. CCA можно реализовывать через HTTP, чего нельзя делать в WebAuthn. Также у CCA проблемы с портативностью и легкостью использования.

    Я не считаю, что Альянс изобрел что-то новое. Мы просто разработали хороший протокол, который включает в себя уже существующие механизмы защиты.


    / Flickr / Markus Spiske / PD

    Не откроет ли использование стандарта дополнительные векторы атак, связанные с тем, что потребуется хранить большое количество биометрической информации?


    Один из наших фундаментальных принципов — обеспечение приватности. Биометрическая информация хранится на безопасных чипах и никогда их не покидает. Наши компании работают со считывателями, сертифицированными FIDO или FIPS.

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

    Вы как-то говорили, что аутентификация по SMS-коду — это плохой вариант 2FA. Как вы можете это прокомментировать?


    SMS-коды или SMS OTP — это двухфакторная аутентификация на одноразовых паролях, доставленных по SMS. Поэтому получается, что это решение уязвимо для фишинга. Если ваш пользователь попался на фишинг и отдал свой логин и пароль, что остановит его от передачи злоумышленникам еще и SMS-кода?

    Нельзя забывать и о проблемах использования SMS в качестве транспорта. Три года назад в немецком банке были взломаны 400 тыс. аккаунтов из-за уязвимости в протоколе SS7, который используется для маршрутизации телекоммуникационной информации между разными операторами связи. Атакующие, получившие несанкционированный доступ к сети SS7, в которой отсутствует какая-либо аутентификация, смогли зарегистрировать номера жертв на себя и получить их коды.

    Также на сегодняшний день каждый может за 500–600 долларов купить базовую GSM-станцию и перехватить с её помощью SMS, используя MITM-атаку. Ну и, наконец, существуют опасности, связанные с социальной инженерией. Я думаю, многие знакомы с историей, когда злоумышленники похитили солидную сумму денег с банковских счетов, оформив выдачу дубликата сим-карты жертвы. Такое случается в России и других странах с завидной регулярностью.

    Как быть, если нужно войти в сервис на нескольких устройствах или одним и тем же сервисом пользуется сразу несколько человек? Поддерживается ли стандартом такой режим работы?


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

    А что делать, если токен был утерян? Можно ли будет вернуть доступ к сервисам?


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

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

    Самым перспективным решением на сегодняшний день является Delegated Recovery — это рекавери-протокол на основе хранения зашифрованных секретов в других сервисах. Его, кстати, написал один из создателей U2F Братт Хилл (Bratt Hill). Рекавери — это довольно тяжелая и интересная проблема, решение которой нам еще предстоит найти.

    Приватный ключ в аутентификаторе должен быть защищен от копирования. В каком виде и где хранятся идентификаторы? Как происходит обмен ими?


    При каждой регистрации аутентификатор генерирует новую уникальную пару ключей и присваивает ей случайный идентификатор, который называют credential ID или credID. Приватные ключи хранятся в безопасном хранилище, как, например, SecureEnclave, TPM или TEE.

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

    Как новый стандарт будет соотноситься с требованиями законов о защите данных (например, GDPR)?


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

    И кто уже внедряет стандарт?


    Google, Facebook, Dropbox, Salesforce, Bank of America, NTT Docomo… У нас сотни компаний и полмиллиарда ежедневных пользователей. Мы растем с каждым днем. Но все равно, переход на полную беспарольную аутентификацию займет некоторое время.

    Как быстро стандарт позволяет осуществить переход с другого метода аутентификации?


    Переход с существующих решений двухфакторной аутентификации (например, с OTP) на FIDO довольно прост. Нужно просто подключить библиотеку и реализовать пару изменений на клиентской стороне. В FIDO2 опция для беспарольной аутентификации — это просто дополнительный флаг при регистрации. Перевод же всей экосистемы на полную беспарольную аутентификацию займет некоторое время. Мы прогнозируем, что за 10 лет этот переход совершит 80% всех сервисов.

    Какие планы у FIDO по развитию стандарта? Какие улучшения планируется произвести уже в ближайшее время? А в долгосрочной перспективе?


    Пока что мы сконцентрировались на продвижении стандартов. В мире миллионы сайтов — это значит, что у нас миллион дел. В долгосрочной перспективе мы планируем поработать над внедрением стандартов в сфере интернета вещей, чтобы повысить безопасность IoT-гаджетов. Также в планах работа над государственными системами аутентификации, eID, паспортами и децентрализованными системами идентификации.

    Как вы планируете продолжать работу над WebAuthn? Как вам могут помочь участники ИТ-сообщества?


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



    P.S. Юрий Аккерманн также подготовил статью на Хабре, в которой описал основные механизмы безопасности FIDO2 и рассмотрел JS API для работы с ним.
    1cloud.ru
    IaaS, VPS, VDS, Частное и публичное облако, SSL

    Comments 10

      +2
      Общий вопрос есть: по сути аутентификатором может быть и сам клиент (то же модернизированное хранилище паролей в браузере), ну или можно иметь несколько аппаратных аутентификаторов, праивльно? А предусмотрен механизм синхронизации ключей между ними? Или один девайс — одна регистрация? Или под одним аккаунтом нужно регистрировать все девайсы/браузеры? Если последнее, то как подтвердить правомерность добавления девайса к аккаунту? только с помощью уже добавленного (например при первичной регистрации) девайса?
        +1
        о сути аутентификатором может быть и сам клиент (то же модернизированное хранилище паролей в браузере), ну или можно иметь несколько аппаратных аутентификаторов, праивльно? Или один девайс — одна регистрация? Или под одним аккаунтом нужно регистрировать все девайсы/браузеры?

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


        А предусмотрен механизм синхронизации ключей между ними? Если последнее, то как подтвердить правомерность добавления девайса к аккаунту? только с помощью уже добавленного (например при первичной регистрации) девайса?

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


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


        Мы все еще работаем над рекомендационным документом по аутентификационным сценариям.

        +1

        У меня вопрос такого плана: FIDO2, по описанию, является протоколом однофакторным с аутификацией по владению. Аутификация по знанию как прикручивается — условный токен надо делать с PIN-кодом?

          0

          FIDO2 может работать либо в полностью беспарольно режиме либо в режиме второго фактора.


          Если используется режим второго фактора, то идет классическая схема пересылки пароля с последующим вторым фактором.


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

            +1

            То есть я правильно понял, что во втором случае фактор пароля реализуется на уровне самого токена? Благодарю!


            И заодно ещё один вопрос: у дешёвых токенов U2F, как мне кажется, есть недостаток, что различным сервисам видна одна и та же Identity токена, а значит возможно отслеживание пользователя, пока он пользуется одним токеном во многих сервисах. Решается ли это в FIDO2, или этого недостатка и не было?

              0

              В FIDO мы реализуем приватность с помощью двух механизмов:


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


              2. При регистрации, аутентификатор возвращает аттестационный сертификат партии. Данный сертификат устанавливается на более чем сто тысяч устройств. Так что приватность сохранена.



              Все устройства FIDO одинаково реализуют протокол вне зависимости от цены устройства

        +9

        Фидошники негодуют!
        Прилепили зарезервированное слово к какой-то новой поделке..

          +4
          Я негодую!
          © Фердыщенко. Тоже, из-за ключевого слова, открыл статью.
            0
            А я вообще подумал по заголовку что Юрий Акерман это настоящее имя Мицгола, и речь идет о гипертекстовом фидонете.

        Only users with full accounts can post comments. Log in, please.