Что такое аттестация в WebAuthn?

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

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

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

   • формат заявления об аттестации (fmt)
   • заявление об аттестации (attStmt - см. ниже)
   • данные аутентификатора (authData)

3. В-третьих, в WebAuthn заявление об аттестации является необязательным элементом объекта аттестации. Это заявление, если оно включено, подтверждает определенные характеристики аутентификатора (устройства), участвующего в процессе аттестации. Однако некоторые производители устройств (например, Apple) не предоставляют заявление об аттестации, поскольку этот аспект спецификации не был предназначен для синхронизации ключей доступа и не позволяет эффективно проверять атрибуты безопасности, когда учетные данные могут синхронизироваться между различными устройствами (например, ключ доступа создается на iPhone, но также используется на MacBook, так как он синхронизируется через ту же Связку ключей iCloud). Характеристики, которые могут быть предоставлены при наличии заявления об аттестации:

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

Следующая схема процесса регистрации показывает роль аттестации (объекта) в WebAuthn:

{
    "root": {
        "id": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "response": {
            "attestationObject": {
                "fmt": "none",
                "attStmt": {},
                "authData": {
                    "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                    "flags": {
                        "userPresent": true,
                        "userVerified": true,
                        "backupEligible": true,
                        "backupStatus": true,
                        "attestedData": true,
                        "extensionData": false
                    },
                    "counter": 0,
                    "aaguid": "00000000-0000-0000-0000-000000000000",
                    "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
                    "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
                    "parsedCredentialPublicKey": {
                        "keyType": "EC2 (2)",
                        "algorithm": "ES256 (-7)",
                        "curve": 1,
                        "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
                        "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
                    }
                }
            },
            "clientDataJSON": {
                "type": "webauthn.create",
                "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
                "origin": "https://passkeys.eu",
                "crossOrigin": false
            },
            "transports": ["hybrid", "internal"],
            "publicKeyAlgorithm": -7
        },
        "authenticatorAttachment": "cross-platform"
    }
}

В приведенном выше примере не предоставлены AAGUID и заявление об аттестации.

Экспериментируйте с passkey-флоу в Passkeys Debugger.

Попробовать бесплатно

Продолжайте чтение для технического разбора наиболее важных атрибутов.

В WebAuthn аттестация обеспечивает безопасность и прозрачность аутентификации пользователя. С помощью заявления об аттестации вы можете убедиться, что учетные данные были созданы на конкретном аутентификаторе / устройстве.

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

• Без аттестации (none): В случаях, когда конфиденциальность имеет первостепенное значение или используются синхронизированные устройства, этот тип не предоставляет никакой информации об устройстве, обеспечивая неприкосновенность частной жизни пользователя. Еще одной причиной использования этого значения может быть экономия времени на обращение к центру сертификации (CA). none также является значением по умолчанию.
• Непрямая аттестация (indirect): Доверяющая сторона предпочитает получить аттестацию, но позволяет клиенту решать, как получать заявления об аттестации. Клиент может заменять сгенерированные аутентификатором заявления об аттестации анонимными заявлениями для защиты конфиденциальности пользователя.
• Прямая аттестация (direct): Это наиболее прозрачная форма. Здесь доверяющая сторона сообщает аутентификатору, что хочет получить заявление об аттестации, чтобы доверяющая сторона получила подробную информацию об устройстве, включая его марку, модель и другие детали. Хотя это обеспечивает максимальную прозрачность, это может вызывать опасения по поводу конфиденциальности в определенных сценариях или быть неприменимым для синхронизированных учетных данных.
• Корпоративная аттестация (enterprise): Доверяющая сторона хочет получить заявление об аттестации, которое может содержать уникальную идентифицирующую информацию. Этот тип аттестации обычно используется в компаниях или организациях, которые хотят отслеживать конкретные устройства / аутентификаторы. Веб-браузеры (пользовательские агенты) не должны предоставлять такую подробную аттестацию, если их настройки не разрешают это специально для запрашивающей стороны. Если настройки это разрешают, браузер должен сообщить устройству, когда это необходимо (в начале процесса), что запрашивается именно этот тип аттестации. Затем браузер должен передать уникальный идентификатор устройства и доказательство аттестации в точности так, как он их получил, доверяющей стороне.

Подпишитесь на наш Passkeys Substack, чтобы получать новости.

Подписаться

Объект аттестации содержит множество атрибутов, вот краткое объяснение некоторых из них:

"attestationObject": {
        "fmt": "none",
        "attStmt": {},
        "authData": {
          "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
          "flags": {
            "userPresent": true,
            "userVerified": true,
            "backupEligible": true,
            "backupStatus": true,
            "attestedData": true,
            "extensionData": false
          },
          "counter": 0,
          "aaguid": "00000000-0000-0000-0000-000000000000",
          "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
          "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
          "parsedCredentialPublicKey": {
            "keyType": "EC2 (2)",
            "algorithm": "ES256 (-7)",
            "curve": 1,
            "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
            "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
          }
        }

attestationObject — это объект, закодированный в формате CBOR, содержащий информацию о вновь созданных учетных данных, открытом ключе и другие важные данные:

• fmt представляет формат аттестации, поскольку аутентификаторы могут предоставлять данные аттестации различными способами. Он сообщает серверу, как тот должен проверять данные аттестации. Допустимые значения: "packed", "tpm", "android-key", "android-safetynet", "fido-u2f", "apple" или "none". Подробности см. здесь
• attStmt — это заявление об аттестации. Для ключей доступа, например, на устройствах iOS или Android, оно остается пустым, так как ключи доступа на iOS или Android могут синхронизироваться, и заполняется для других устройств, таких как Windows или аппаратные ключи безопасности.
• authData — это буфер значений, содержащий следующие данные:
  
  Данные аттестованных учетных данных играют здесь важную роль. Они содержат:
  • AAGUID,
  • Длину ID учетных данных,
  • ID учетных данных и
  • Открытый ключ учетных данных.

В отличие от объекта аттестации выше, где attStmt был оставлен пустым для удобства чтения, вот как будет выглядеть заполненное заявление об аттестации.

{
    "alg": -65535,
    "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ",
    "ver": "2.0",
    "x5c": [
        "MIIFwDCCA6oIaK6tZ7M",
        "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM"
    ],
    "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w",
    "certInfo": "_1RDR4AXAniCekfsiDI"
}

• alg: Свойство alg указывает идентификатор криптографического алгоритма, используемого аутентификатором для подписи заявления об аттестации.
• sig: Свойство sig содержит цифровую подпись, сгенерированную аутентификатором. Эта подпись используется для проверки подлинности заявления об аттестации.
• ver: Свойство ver указывает версию формата заявления об аттестации.
• x5c: Массив x5c содержит один или несколько сертификатов X.509, которые образуют путь сертификации, помогающий в проверке аттестации.
• pubArea: Свойство pubArea содержит подробную информацию об открытом ключе и характеристиках аутентификатора.
• certInfo: Свойство certInfo обычно включает информацию о сертификации аутентификатора доверенной стороной.

"clientDataJSON": {
        "type": "webauthn.create",
        "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
        "origin": "https://www.passkeys-debugger.io",
        "crossOrigin": false
      }

Узнайте больше о clientDataJSON в соответствующей статье глоссария.

"transports": [
        "hybrid",
        "internal"
      ]

Свойство transports указывает механизмы, с помощью которых аутентификатор может взаимодействовать с клиентом. Некоторые распространенные примеры комбинаций значений:

• "transports": ["internal","hybrid"]: Ключи доступа можно использовать с платформенного аутентификатора (например, Face ID, Touch ID, Windows Hello) или через межплатформенную аутентификацию (с использованием QR-кода и Bluetooth).
• "transports": ["internal"]: Ключи доступа можно использовать с платформенного аутентификатора (например, Face ID, Touch ID, Windows Hello)
• Свойство transports не установлено: поведение по умолчанию, которое не дает никаких указаний.

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

Igor Gjorgjioski

Head of Digital Channels & Platform Enablement, VicRoads

We hit 80% mobile passkey activation across 5M+ users without replacing our IDP.

See how VicRoads scaled passkeys to 5M+ users — alongside their existing IDP.

Read the case study

Да, поскольку ключи доступа могут синхронизироваться между устройствами (например, с iPhone на MacBook через Связку ключей), доверяющие стороны больше не могут точно определить, какое именно аттестованное устройство входит в приложение или на веб-сайт. Поэтому Apple и Google решили, что для синхронизированных ключей доступа они больше не будут предоставлять заявления об аттестации. Однако, чтобы улучшить пользовательский опыт для доверяющих сторон и дать им возможность распознавать и отображать ключи доступа из экосистем Apple и Google (Связка ключей iCloud и Менеджер паролей Google), AAGUID по-прежнему будет предоставляться (при условии, что для аттестации установлено значение direct или indirect в настройках сервера WebAuthn для PublicKeyCredentialCreationOptions. Подробности см. в этом обсуждении на GitHub).

Если вы хотите интегрировать аутентификацию по ключам доступа на свой веб-сайт и в приложение и хотите предложить пользователям отличный опыт использования ключей доступа, вам следует учесть следующее. Мы предполагаем, что вы создаете свое решение в первую очередь для сценария, где большинство ваших пользователей используют операционные системы Windows, iOS, macOS или Android. Кроме того, мы предполагаем, что большинство ключей доступа (кроме Windows) являются синхронизированными. Поскольку ни iOS, ни macOS, ни Android больше не отправляют заявление об аттестации, реальная проверка аутентификатора больше не используется (для Windows это все еще работает, вероятно, потому что Windows пока не предлагает синхронизированные ключи доступа через Windows Hello). Однако, чтобы получить AAGUID, например, для лучшего управления ключами доступа в настройках учетной записи, мы рекомендуем установить предпочтение аттестации на indirect, так как это все равно позволит получить AAGUID, в то время как заявление об аттестации будет либо отправлено (Windows), либо нет (iOS, macOS, Android).

Сервис метаданных FIDO предоставляет репозиторий метаданных для различных аутентификаторов. Во время аттестации к этому сервису можно обратиться для получения и проверки сведений об аутентификаторе, что обеспечивает точность и повышает надежность процесса. Сервис метаданных FIDO проверяет заявление об аттестации (а не объект аттестации).

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

WebAuthn предлагает различные типы предпочтений аттестации — none, indirect, direct и enterprise. В сценариях, где важна конфиденциальность пользователя, можно использовать attestation=none, который не предоставляет никаких сведений об устройстве, обеспечивая защиту частной жизни пользователя.

О Corbado

Corbado — это Passkey Intelligence Platform для CIAM-команд, обеспечивающих аутентификацию пользователей в крупных масштабах. Мы показываем то, что не видят логи IDP и общие инструменты аналитики: какие устройства, версии ОС, браузеры и менеджеры учётных данных поддерживают passkey, почему регистрации не превращаются в логины, где сбоит WebAuthn-поток и когда обновление ОС или браузера тихо ломает вход — всё это без замены Okta, Auth0, Ping, Cognito или вашего собственного IDP. Два продукта: Corbado Observe добавляет наблюдаемость для passkey и любых других способов входа. Corbado Connect даёт managed passkey со встроенной аналитикой (рядом с вашим IDP). VicRoads использует passkey для более чем 5 млн пользователей с Corbado (+80 % активации passkey). Поговорить с экспертом по passkey →