FIDO - Как сервер FIDO проверяет целостность входящего открытого ключа во время фазы / церемонии регистрации?

Question

Пытаюсь обернуть голову вокруг протокольного костюма FIDO.

посылка

1. Аутентификатор имеет главный закрытый ключ (также называемый ключом подтверждения)
   
2. Во время церемонии регистрации аутентификатор подписывает запрос и несколько других параметров вместе с вновь созданным открытым ключом и отправляет его на универсальный сервер FIDO по протоколу WebAuthN. И сгенерированный закрытый ключ хранится в аутентификаторе локально.

Вопросы

1. Как сервер FIDO проверяет целостность открытого ключа, сгенерированного аутентификатором (проще говоря, как сервер проверяет цепочку сертификатов до корня доверия)? Предполагается, что между средством проверки подлинности и веб-клиентом есть возможность для атаки с помощью MIT.
   
2. Имеется ли на сервере соответствующий открытый ключ ключа аттестации / главного секретного ключа (репликация модели CA)?
   
3. Если да, все ли аутентификаторы fido имеют один и тот же мастер-ключ при создании (будь то программный модуль или аппаратный модуль)? Если нет, то как производители и серверы FIDO следят за созданием и развертыванием огромного количества физических аутентификаторов и программных модулей?

Answer 1

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

Шаг 15 "Регистрация нового удостоверения" в Рекомендации WebAuthn W3C гласит:

Если проверка прошла успешно, получите список приемлемых якорей доверия (корневые сертификаты аттестации или открытые ключи ECDAA-Issuer) для этого типа аттестации и формата fmt оператора аттестации из доверенного источника или из политики. Например, служба метаданных FIDO [FIDO Metadata Service] предоставляет один способ получения такой информации, используя aaguid в attestedCredentialData в authData.

Выдержка из https://fidoalliance.org/mds/:

Служба метаданных FIDO Alliance (MDS) - это веб-инструмент, с помощью которого поставщики средств проверки подлинности FIDO могут публиковать операторы метаданных для загрузки на серверы FIDO. Это обеспечивает организациям, развертывающим серверы FIDO, централизованный и надежный источник информации о средствах проверки подлинности FIDO.

Answer 2

1. В аутентификатор вводится закрытый ключ (ключ аттестации) перед тем, как он будет продан пользователю. Сертификату аттестации доверяет сервер FIDO. Этот сертификат будет использоваться для проверки подписи в заявлении об аттестации. Поговорим о доверии сертификату. Есть 2 вида доверия: доверие и цепочка доверия.

Доверие: сервер FIDO напрямую импортирует (хранит) известный сертификат поставщика аутентификатора. Допустим, я доверяю Yubico, я загружаю сертификат аттестации ключа Yubico с сайта Yubico и импортирую его на свой сервер FIDO. Этот сертификат будет использоваться для проверки регистрации пользователей, использующих ключи Yubico. Никто не может сгенерировать действительное заявление об аттестации без приватного подтверждения. Не беспокойтесь о человеке посередине, потому что поставщики, возможно, применили технологию безопасного чипа для защиты закрытого ключа.

Цепочка доверия: сервер FIDO, очевидно, доверяет службе метаданных FIDO (MDS) и просто хранит сертификаты MDS. MDS выдает сертификаты для поставщиков аутентификаторов. Итак, когда аутентификатор создает заявление об аттестации и отправляет его на сервер FIDO, Сервер проверяет подпись, используя сертификат аттестации в заявлении об аттестации, а затем объединяет сертификат аттестации с сертификатами MDS для выполнения проверки.

Обратите внимание, что мы говорим о полной базовой модели аттестации, которая на данный момент является наиболее распространенной. ECDAA будет другим.

2. Как объяснено в 1. выше. Сервер МОЖЕТ или НЕ МОЖЕТ иметь открытый ключ аттестации. Обратите внимание, что закрытые ключи аттестации в аутентификаторах НЕ различаются. Продавцы производят ключи безопасности партиями. Каждому пакету они вводят одну и ту же частную аттестацию, это для конфиденциальности пользователя. Это не идеальное решение. Конфиденциальность пользователей прекрасно решается не запущенным ECDAA.

3. Как поясняют 1., 2.

Answer 3

Ok. Давайте поговорим об аттестации, mds и метаданных.

У устройств есть вещь, называемая аттестацией. Это способ определить модель устройства. в общем сценарии, подобно ключу безопасности, т. е. Yubikey, Trustkey и т. д., производитель сгенерирует сертификат пакета аттестации и закрытый ключ, а затем поместит его в партию устройств.

Затем корень пакетного сертификата помещается в метаданные, цифровой документ, описывающий свойства устройства (имя, идентификатор модели, алгоритмы, свойства безопасности и т. д.).

Затем метаданные сохраняются в службе метаданных, MDS и централизованном хранилище, управляемом FIDO Alliance для метаданных.

Сервер FIDO время от времени получает MDS и загружает все метаданные. Во время регистрации устройство вернет аттестацию, которую можно проверить, найдя соответствующие метаданные с использованием идентификатора модели (AAGUID или AAID) и используя корневой сертификат из метаданных, проверив подпись аттестации, созданную устройством с помощью пакета. ключ.

Теперь вот что. Это все круто и модно, но на самом деле, в большинстве случаев, вам не нужна аттестация. Большинство сервисов просто хотят использовать безопасную аутентификацию с помощью паролей, поэтому по умолчанию WebAuthn API возвращает вам аттестацию «Нет». Нет, когда браузер удаляет информацию об аттестации из соображений конфиденциальности.

Если вы хотите узнать больше, есть отличная статья, в которой подробно рассказывается об аттестации: https://medium.com/webauthnworks/webauthn-fido2-demystifying-attestation-and-mds-efc3b3cb3651 .