Аутентификация fido что такое
Защитный ключ Fido на телефоне андроид: что это такое
06.06.2020 9,444 Просмотры
Мы живем в такое время, когда необходимо всегда заботиться о персональной безопасности. Но, а так как мы живем во время цифровых технологий, то прежде всего нужно позаботиться о безопасности наших данных в сети, на нашем смартфоне, онлайн-банкинге, электронной почте и так далее. И в сегодняшней статье речь пойдёт о защитном ключе Fido, а также двухфакторной аутентификации, как более безопасный способ защиты ваших данных.
Что же такое FIDO, двухфакторная аутентификация, как это работает на устройствах
Учитывая тот факт, насколько технологии прошли вперёд, что теперь практически у каждого есть возможность носить у себя в кармане смартфон, который сопоставим с мощными компьютерами и носителями важной информации. Сейчас можно любой смартфон сделать своим ключом для двухфакторной аутентификации. И если вы хотите максимально защититься, тогда используете её абсолютно для всех своих личных аккаунтов в сети.
Самыми популярными, а также самыми уязвимыми мишенями становятся сервисы Google, которые неоднократно подвергаются хакерским атакам. Но, чтобы защитить своих клиентов, разработчики сделали специальные способы защиты в виде ключей в несколько шагов. И если пользователь захочет войти в свои аккаунты, тогда он обязательно должны пройти все эти шаги.
Для кого доступны эти возможности
Как правило, все эти мери безопасности были придуманы для более уязвимых людей, а именно для:
Но, сейчас все эти функции доступны для каждого, поэтому никогда не будет лишним сделать свой аккаунт неприступной крепостью.
Как настроить
Если вы решились проделать все эти действия, тогда вам следует перейти в настройки своего телефона, к безопасности, аккаунт Google, а потом к двухфакторной аутентификации. Затем просто добавьте электронный ключ и дело в шляпе.
FIDO: биометрическая технология, которая защитит ваши пароли
Наиболее популярным способом обеспечить защиту профиля пользователя на сайте сегодня является двухфакторная аутентификация: вы вводите пароль, и на ваш телефон приходит смс с кодом, который нужно ввести в еще одно поле. Однако даже эта технология сегодня не считается идеальной.
На помощь приходят биометрические технологии — в частности, технология, называемая FIDO.
Как работает FIDO
Природа паролей побуждает нас быть ленивыми. Длинные, сложные пароли (самые безопасные) для нас сложнее всего создать и запомнить. Поэтому многие берут какой-то простой пароль, немного его «дорабатывают» и пользуются — это огромная проблема, потому что у хакеров давно есть списки популярных паролей. И хакеры автоматизируют атаки путем «заполнения учетных данных», пытаясь найти, что именно вы добавили к вашему «стандартному» паролю.
FIDO работает на основе распознавания лиц и отпечатков пальцев — это умеют многие современные смартфоны.
«Пароль — это то, что вы знаете. Устройство — это то, что у вас есть. Биометрия — это то, чем вы являетесь. Мы движемся к тому, что пароль всегда будет при вас — и нужда в его запоминании просто отпадет», — сказал Стивен Кокс, главный архитектор безопасности SecureAuth.
FIDO, или Fast Identity Online, стандартизирует использование аппаратных устройств (сканер отпечатков пальцев, камеры) для создания уникальной «биометрической карточки», которая и позволит пользователю регистрироваться и заходить на сайты.
Подделать отпечатки пальцев или лицо намного сложнее и дороже — так что, по мнению Эндрю Шикиара, исполнительного директора FIDO Alliance, «… в течение следующих пяти лет у каждой крупной потребительской интернет-услуги будет альтернативная регистрация без пароля».
FIDO также выгоден и компаниям, поскольку устраняет опасения по поводу утечек данных (в частности, конфиденциальной информации клиентов). Похищенные «биометрические карточки» не позволят хакерам войти в систему, потому что их надо не просто ввести, но и подтвердить.
Вот один из способов входа на основе FIDO без паролей. Вы открываете страницу входа в систему на своем ноутбуке, вводите имя пользователя, нажмите кнопку, а затем пользуетесь биометрической аутентификацией ноутбука, например, Touch ID от Apple или Windows Hello. Если ваша система не оснащена нужными устройствами, вы можете подключить по Bluetooth телефон — и точно так же использовать FIDO.
Технология готова — готовы ли мы?
Большим преимуществом этого подхода является то, что устройство безопасности FIDO (телефон, ноутбук, иной гаджет) не будут работать с фальшивыми сайтами, потому что ключи безопасности регистрируются только для сайтов-оригиналов.
«Вместо того, чтобы «грузить» пользователя проверкой сайта, мы переложили ее на систему», — отметил Марк Ришер, руководитель отдела аутентификации в Google, в своем блоге.
В компании уже более 10 000 сотрудников перешли на подобный способ, что сократило число взломов их аккаунтов практически до нуля.
Однако у некоторых экспертов есть опасения: а захотят ли люди разрешать использование своих данных? Одно дело — цифры и буквы, а другое — отпечатки пальцев и снимки лица.
«Имена пользователей и пароли по-прежнему будут наиболее распространенным вариантом. Пока есть выбор и пока популярна тема «тотального контроля» на основе биометрических данных, люди будут работать по старинке», — отмечают они.
Добавьте «Правду.Ру» в свои источники в Яндекс.Новости или News.Google, либо Яндекс.Дзен
Быстрые новости в Telegram-канале Правды.Ру. Не забудьте подписаться, чтоб быть в курсе событий.
Юрий Аккерманн: «Один из фундаментальных принципов FIDO Alliance — обеспечение приватности»
Интервью со старшим сертификационным инженером FIDO Alliance о беспарольной аутентификации
Наши пользователи попросили нас реализовать двухфакторную аутентификацию через приложение Google. И недавно мы эту возможность им предоставили. Примерно в то же время консорциум FIDO Alliance опубликовал стандарты для беспарольной аутентификации на сайтах, в мобильных приложениях и веб-сервисах — WebAuthn и CTAP.
Мы заинтересовались этой темой и подготовили материал на Хабре, в котором поговорили о методах, лежащих в основе новых протоколов.
Затем, чтобы прояснить некоторые моменты, касающиеся тонкостей работы стандарта, мы пообщались с Юрием Аккерманном (herrjemand), старшим сертификационным инженером FIDO Alliance. Он ответил на несколько наших вопросов о прошлом, настоящем и будущем аутентификации FIDO. Представляем вашему вниманию текст интервью.
Расскажите, пожалуйста, о своем бэкграунде и опыте работы в 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? Как вам могут помочь участники ИТ-сообщества?
Я, как и раньше, продолжаю свою работу посла в сообществе разработчиков: публикую статьи, тружусь над опенсорсом, делаю презентации, провожу тренинги. Насчет помощи сообщества я могу только сказать: «Нужно больше золота опенсорса».
FIDO2 — Пароли must die
Думаю, все вы неоднократно слышали о том что «пароли мертвы», «пароли вымирают», «новая технология убьет пароли» и тому подобное.
Мы в FIDO Alliance как раз-таки пришли сообщить вам о том, что пароли все-таки вымрут… в аутентификации.
Прежде чем мы начнем разговор о массовом уничтожении многословных гадов, давайте вернемся к нашему самому популярному протоколу FIDO U2F о коем я писал ранее.
То есть сценарий аутентификации с U2F таков:
Регистрация:
— Пользователь регистрируется, используя логин и пароль
— Сервер хеширует пароль с использованием scrypt, argon2, bcrypt и сохраняет в БД
— Пользователь добавляет свое устройство, храня на сервере публичный ключ и id пары ключей на устройстве
Аутентификация:
— Пользователь вводит логин и пароль
— Сервер хеширует пароль и сравнивает с хешем в базе данных
— Сервер генерирует случайный «вызов» и отправляет клиенту вместе с ID
— Клиент передает вызов, id, token binding, и origin сессии U2F токену
— Аутентификатор все это подписывает приватным ключом и отправляет клиенту, а тот серверу
— Профит
На сегодняшний день мультифакторная аутентификация с использованием U2F является самым легким, фишинг устойчивым и безопасным методом аутентификации. Но даже у этого метода есть свои недостатки.
Пароли все еще можно украсть на всех стадиях аутентификации:
— Можно украсть с помощью кейлоггера;
— Можно украсть при проблемах с TLS(см Heartbleed);
— Можно украсть если сервер уязвим к инъекции кода, или при ошибках в коде(см Twitter)
— Можно украсть если пароли слабо хешированы или не были хешированы вовсе.
Пока есть пароль, его можно украсть
А что если убрать пароль вообще?
Собственно, так подумали мы в FIDO Alliance (мы не имеем ничего общего с гипертекстовым фидонетом, хотя потенциально можем быть там использованы) и сделали FIDO2
Для тех, кто о нас не слышал, FIDO Alliance — это консорциум, разрабатывающий открытые стандарты безопасной аутентификации. Выше на картинке вы можете видеть наших членов совета, которые собственно и разрабатывают стандарты.
FIDO2 — это наш последний проект, который мы разрабатывали более трех лет. Он состоит из двух частей:
— WebAuthn — JS API для менеджмента учетных записей на публичных ключах. Это W3C стандарт, так что будет обязателен для всех браузеров. Собственно Chrome, Firefox и Edge уже публично заявили о работе над его поддержкой.
— CTAP2 — Client-to-Authenticator 2 — это стандарт, описывающий CBOR протокол для общения с аутентификатором по USB, NFC и BLE.
Пользователь
Для пользователя это просто:
— Пользователь вводит имя
— Проходит верификацию
— Профит!
Протокол
FIDO2 — это член семейства вызов-ответ протоколов FIDO. В протоколе есть шесть основных механизмов безопасности:
1. Вызов-ответ
Первый механизм это вызов-ответ. Сервер генерирует случайный вызов и отправляет его клиенту. Клиент передает данный вызов аутентификатору, который подписывает вызов и возвращает его клиенту, а тот в свою очередь серверу. Сервер, зная вызов, подпись и публичный ключ, может подтвердить подпись и таким образом аутентифицировать клиента.
2. Фишинг-защита
Второй механизм это сессионно-зависимая транзакция. Когда клиент получает вызов от сервера, он добавляет к вызову информацию о сессии: origin (прим: example.com), token binding. Эта информация подписывается аутентификатором и возвращается серверу. Сервер декодирует ответ и смотрит или в источником был он сам, и если пользователь подвергся фишинг атаке то сервер сможет увидеть что источником был на пример attacker.com а не example.com и таким образом предотвратить атаку.
3. Защита от атаки повторного воспроизведения
Чтобы защитить от атаки повторного воспроизведения, в транзакции присутствует счетчик, который увеличивается на единицу при каждой операции. Если сервер получил ответ со счетчиком, значение которого меньше или равно последнему сохраненному значению, то сервер может точно сказать что это атака повторного воспроизведения.
4. Приватность
Четвертый механизм защиты это регистрационно-уникальные пары ключей. При каждой регистрации аутентификатор генерирует случайную пару ключей со случайным идентификатором. Таким образом даже если вы и ваш партнер будете использовать один аутентификатор для обоих аккаунтов, то сервер не сможет узнать этого.
При аутентификации идентификатор пары ключей передается аутентификатору, и тот, используя origin и идентификатор, найдет вашу пару ключей в своей защищенной БД и вернет подпись.
Альтернатива к передаче идентификатора это использование резидентных ключей (RK, resident keys). При аутентификации аутентификатор вернет подписи для всех RK пар ключей. Клиент предоставляет пользователю выбор пары и вернет подпись серверу. Более подробно RK я распишу ниже.
5. Аттестация
Пятый механизм это аттестация. Иногда сайту нужно узнать тип устройства у пользователя. Так например в США все государственные учреждения обязаны использовать только FIPS (Federal Information Processing Standards) сертифицированные устройства. Подобные требования есть во Франции, Израиле, России и других странах. Для всего этого и существует аттестация.
При производстве аутентификаторов, на каждые сто тысяч устройств компания генерирует «сертификат партии» и ключи к нему и устанавливает их на каждое устройство. При регистрации устройство подписывает всю информацию приватным ключом партийного сертификата и возвращает сертификат вместо публичного ключа. В сертификате содержится информация о аутентификаторе, и его AAGUID(Authenticator Attestation GUID). Также при получении FIDO сертификации компания выпускает специальный документ метадаты, или просто метадату, и помещает в наше хранилище метадаты доступное всем. В метадате содержится информация о аутентификаторе, включая его криптографические характеристики, биометрические характеристики если он поддерживает биометрику, алгоритмы, уровни безопасности, базовое описание и много другой информации. а основе имеющейся информации сервер может судить о том, стоит ли ему принимать аутентификатор или нет.
Аттестация бывает разная. Существует полная версия аттестации, в которой сервер возвращает сертификат. Есть само-аттестация, при которой устройство не поддерживает сертификаты, а вместо этого возвращает публичный ключ только что сгенерированной пары.
Также пользователь может сам настроить метод, с помощью которого он хочет вернуть аттестацию. Так например пользователь может вообще запретить возвращать аттестацию и клиент просто удалит её, вернув регистрационный ответ без аттестации. Об этом я расскажу позже.
6. Тест на наличие пользователя
Одно из фундаментальных требований FIDO это тест на наличие пользователя. В данном случае имеется в виду, что аутентификатор обязан удостоверится в присутствии пользователя… Это может быть сделано по-разному: простое нажатие на кнопку, отпечаток, пин-код и другое.
WebAuthn
В этой секции мы рассмотрим JS API для работы с FIDO2.
Credential Management API
WebAuthn это дополнения к Credential Management API для менеджмента учетных записей публичных ключей. CredMan API это API(неожиданно!) для менеджмента учетных данных пользователя или если выразиться проще: это API для доступа к автозаполнению в браузере.
Далее мы рассмотрим пример создания учетных данных:
А вот пример запроса учетных данных и последующего использования их для аутентификации:
Create public-key credential
Для создания Public-Key Credential мы будем использовать navigator.credentials.create метод, передав ему CreateCredential объект типа «publicKey».
Думаю, код говорит сам за себя, но отмечу при этом несколько моментов:
— challenge и user.id должны быть буферами
— pubKeyCredParams — это список алгоритмов, которые поддерживает сервер. В данный момент сертифицированные сервера FIDO2 обязаны поддерживать: RSA-PSS 2048 с SHA256/384/512, RSA-PKCS1_3 с SHA256/384/512/1, EC с SHA256/384/512, а также кривые secp256/384/521p1(NIST) и secp256k1, и EdDSA ED25519.
— attestation — это собственно вид аттестации, возвращаемой клиентом. Есть три возможные значения: none, direct, indirect. Direct это, собственно, классическая аттестация. None это полное отсутствие аттестации, при котором клиент просто удалит всю аттестационную секцию и заменит AAGUID в ответе на 0x00000000000000000000000000000000. Indirect это аттестация через privacy-ca. По-умолчанию attestation установлена на none. То есть если вы хотите аттестацию, то надо это чётко указать в параметрах. При этом необходимо учитывать, что пользователь все равно может вам отказать в аттестации и вернуть ‘none’ если он того захочет.
Вот пример пример того как пользователь может контролировать аттестацию в Firefox Nightly
В ответ вы получите аттестационный объект:
Здесь вы можете видеть:
— id/rawId — это идентификатор пары ключей на устройстве или credId. id это base64url закодированная версия буфера rawId.
— response.clientDataJSON — это буфер CollectedDataJSON, JSON объекта содержащего сессионную информацию и сам вызов. Пример декодированного clientDataJSON:
— attestationObject — это CBOR объект, содержащий аттестацию, информацию об аутентификаторе, флаги, счётчик и публичный ключ.
— authData — это сырой буфер, содержащий хеш источника или rpIdHash, флаги, счетчик, идентификатор пары ключей, блок с аттестационной информацией и информацию от расширений.
— fmt — это формат аттестации. В данный момент WebAuthn поддерживает «packed», «fido-u2f», «android», «tpm» и «safety-net» аттестации.
— attStmt — это собственно информация по аттестации. Подпись, сертификаты и так далее.
Для верификации подписи мы высчитываем хеш clientDataJSON и получаем clientDataHash. Затем мы объединяем authData и clientDataHash и получаем signatureBase. И в конце мы подтверждаем подпись с помощью attStmt.sig, сертификата или публичного ключа пользователя и signatureBase.
Get assertion
Для того чтобы получить аутентификационую подпись мы будем использовать navigator.credentials.create метод, передав ему объект типа «publicKey».
var randomChallengeBuffer = new Uint8Array(32);
window.crypto.getRandomValues(randomChallengeBuffer);
allowCredentials — это список разрешенных учетных записей, которые идентифицируются идентификатором пары ключей на устройстве (credId). Для двухфакторной аутентификации вы всегда обязаны передавать allowCredentials c credId в запросе. Если во время создания учетной записи мы установили флаг authenticatorSelection.requireResidentialKey, то в дальнейшем обязаны не добавлять поле allowCredentials.
В ответ получаем вот такой объект:
Как вы видите, структура очень похожа, но есть несколько различий:
— clientDataJSON.type теперь типа «webauthn.get»
— attestationObject отсутствует
— authenticatorData это authData, но теперь без authenticatorAttestation секции
— signature это подпись
— userHandle — это идентификатор пользователя, который вы передали во время регистрации в поле user.id
Вычисление подписи работает так же, как и при создании учетной записи.
UPD: Демо webauthn.org (Нужен U2F токен)
На этом я закончу первую часть из цикла статей. В следующей части мы разберем протокол общения клиента и аутентификатора CTAP2(Client-to-Authenticator 2).
Большая благодарность Павлу Замятину за редактуру и орфографию.