--- url: 'https://www.corbado.com/ru/blog/webauthn-pubkeycredparams-credentialpublickey' title: 'WebAuthn pubKeyCredParams и credentialPublicKey: CBOR и COSE' description: 'Узнайте, как WebAuthn использует асимметричные алгоритмы шифрования и pubKeyCredParams при аутентификации с помощью ключей доступа, а также о роли credentialPublicKey, CBOR и COSE.' lang: 'ru' author: 'Vincent Delitz' date: '2025-08-08T11:44:35.663Z' lastModified: '2026-07-28T06:07:08.314Z' keywords: 'pubKeyCredParams, credentialPublicKey, COSE, WebAuthn, криптография с открытым ключом' category: 'WebAuthn Know-How' --- # WebAuthn pubKeyCredParams и credentialPublicKey: CBOR и COSE ## 1. Введение: pubKeyCredParams и credentialPublicKey В цифровой безопасности ключи доступа (passkeys) — это новый стандарт беспарольной аутентификации. В основе ключей доступа лежит криптография с открытым ключом, используемая в протоколе WebAuthn, на котором они базируются. Понимание того, как криптография с открытым ключом используется в WebAuthn, особенно при создании, извлечении, управлении и хранении ключей доступа, имеет решающее значение при разработке или использовании аутентификации с помощью ключей доступа. Открытый ключ хранится на сервере доверяющей стороны (Relying Party, RP), то есть на бэкенде веб-сайта, который хочет аутентифицировать пользователя с помощью ключей доступа, а закрытый ключ надежно хранится в аппаратном модуле безопасности в зависимости от операционной системы: [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) ([iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)), TEE ([Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) или TPM (Windows). В этой статье мы кратко рассмотрим основы криптографии с открытым ключом, используемой в ключах доступа. К концу статьи мы должны получить ответы на следующие вопросы: - **Какие алгоритмы шифрования поддерживаются в WebAuthn** - **Как работают pubKeyCredParams при создании пары ключей?** - **Как работает credentialPublicKey при извлечении созданных открытых ключей?** ## 2. Что такое криптография с открытым ключом? Чтобы понять, как криптография с открытым ключом работает в рамках WebAuthn, мы кратко рассмотрим ее общие принципы и распространенные типы алгоритмов. ### 2.1 Как работает криптография с открытым ключом? Криптография с открытым ключом, также известная как асимметричная криптография, отличается от симметричной, где для шифрования и дешифрования используется один и тот же ключ. Асимметричная криптография использует два разных ключа: открытый ключ, которым можно делиться открыто, и закрытый ключ, который владелец держит в секрете. ![Public Private Keys](https://www.corbado.com/website-assets/public_private_keys_f58d96019d.png)_Взято с: [https://en.wikipedia.org/wiki/Public-key_cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography)_ Этот метод позволяет не только шифровать данные для обеспечения их конфиденциальности, но и подписывать сообщения. Подпись подтверждает личность отправителя и гарантирует, что сообщение не было изменено, тем самым подтверждая его подлинность и целостность. ### 2.2 Распространенные типы алгоритмов криптографии с открытым ключом Вот обзор некоторых распространенных типов алгоритмов, используемых в криптографии с открытым ключом: | **Категория** | **RSA** | **DSA** | **ECDSA** | **EdDSA** | | ----------------------------------------- | ------------------------------------------------ | -------------------------------------------- | ------------------------------------------------------ | --------------------------------------------------- | | **Дата создания** | 1977 | 1991 | 1999 | 2011 | | **Тип алгоритма** | Асимметричная криптография с открытым ключом | Алгоритм цифровой подписи | Цифровая подпись на эллиптических кривых | Цифровая подпись на кривых Эдвардса | | **Основное применение** | Безопасная передача данных | Подписание электронных документов | Безопасные транзакции и подписи | Безопасные транзакции и подписи | | **Распространенные размеры ключей** | от 1024 до 15360 бит | от 1024 до 3072 бит | от 160 до 512 бит | 256 бит | | **Производительность** | Медленнее из-за большого размера ключа | Быстрее RSA для подписи | Быстрые вычисления с малыми ключами | Оптимизирован для скорости и безопасности | | **Популярность** | Широко использовался исторически | Менее распространен, чем RSA | Становится все более популярным | Быстро набирает популярность | | **Эффективность для мобильных устройств** | Менее эффективен на мобильных устройствах | Умеренно эффективен | Высокая эффективность на мобильных устройствах | Максимальная эффективность | | **Требования к хранению ключей** | Высокие из-за больших размеров ключей | Умеренные | Требуется мало места для хранения | Минимальные потребности в хранении | | **Расход батареи** | Более высокое потребление | Умеренное потребление | Низкое энергопотребление | Оптимален для сохранения заряда батареи | | **Пригодность для мобильных устройств** | Менее подходит из-за размера и энергопотребления | Умеренно подходит | Очень подходит | Очень подходит | | **Применение в стандартах** | Широко применяется (TLS, SSH) | Менее широко применяется | Широко применяется в современных протоколах (TLS, SSH) | Набирает популярность в новых протоколах (TLS, SSH) | | **Устойчивость к будущим угрозам** | Уязвим для квантовых атак | Уязвим для квантовых атак | Потенциально устойчив к квантовым атакам | Потенциально устойчив к квантовым атакам | | **Универсальность** | Высокая универсальность на разных платформах | Ограничен конкретными случаями использования | Высокая универсальность | Высокая универсальность | | **Патентный статус** | Не защищен патентом | Не защищен патентом | Не защищен патентом | Не защищен патентом | Математическая основа криптографии на эллиптических кривых (ECC), включая ECDSA и EdDSA, связана со свойствами эллиптических кривых, которые мы не будем рассматривать в этой статье. Но из приведенной выше таблицы очевидно, что существуют преимущества, которые способствуют их внедрению. Мы рассмотрим самые важные из них в следующем разделе. ### 2.3 Растущее внедрение криптографии с открытым ключом на основе ECC Криптография на эллиптических кривых получила широкое распространение на мобильных устройствах, поскольку они выигрывают от меньших размеров ключей, что дает следующие преимущества: - **Снижение требований к хранилищу:** Меньшие ключи ECC требуют меньше места для хранения по сравнению с традиционными криптографическими методами, такими как RSA. Это особенно полезно для устройств с ограниченными ресурсами памяти, что позволяет более эффективно использовать пространство. В следующей таблице показано приблизительное соответствие уровней безопасности и фактических размеров используемых ключей. Уровень безопасности измеряется в битах и обычно соответствует симметричному шифру с ключом такого же размера: | **Уровень безопасности (биты)** | **Размер ключа RSA (биты)** | **Размер ключа ECDSA/EdDSA (биты)** | | ------------------------------- | --------------------------- | ----------------------------------- | | 80 | 1024 | 160-223 | | 112 | 2048 | 224-255 | | 128 | 3072 | 256-383 | | 256 | 15360 | 512+ | Термин **уровень безопасности** в этом контексте относится к стойкости криптографической системы, а именно к уровню сложности, с которым столкнется злоумышленник при попытке обойти меры безопасности. Обычно он измеряется в битах и представляет собой объем работы (количество операций), который потребуется для взлома шифрования или подделки подписи. С ростом уровня безопасности преимущества в размере становятся очевидными, достигая соотношения размеров ключей до 1:30. - **Повышенная производительность:** Меньшие ключи обеспечивают более быстрые криптографические операции, что крайне важно для устройств с меньшей вычислительной мощностью. Это приводит к ускорению шифрования и дешифрования, повышая общую производительность и отзывчивость мобильных приложений. В зависимости от типа тестов производительности [ускорение выполнения может составлять от 10 до 40 раз](https://aws.amazon.com/de/blogs/networking-and-content-delivery/cloudfront-now-supports-ecdsa-certificates-for-https-connections-to-origins/). Вот пример данных тестирования, которые [AWS](https://www.corbado.com/blog/passkeys-amazon-cognito) провела при внедрении ECDSA для Cloudfront в 2018 году: | **Алгоритм** | **Размер ключа** | **Операция подписи** | **Подписей/с** | | ------------ | ---------------- | -------------------- | -------------- | | RSA | 2048 | 0.001012s | 987 | | ECDSA | 256 | 0.000046s | 21565 (x20) | - **Повышенная энергоэффективность:** Благодаря более эффективной обработке с меньшими ключами, операции ECC могут потреблять меньше энергии. Эта экономия [энергии](https://www.corbado.com/passkeys-for-energy) жизненно важна для мобильных устройств, где сохранение заряда батареи является постоянной задачей. Эти факторы делают ECC особенно подходящей для мобильных сред, где оптимизация хранилища, скорости обработки и энергопотребления имеет важное значение. В результате ECC все чаще предпочитают в мобильных вычислениях за ее способность обеспечивать надежную безопасность без ущерба для производительности устройства. Тем не менее, до сих пор существует множество старых версий распространенных протоколов, таких как TLS (используемый для HTTPS, FTPS или SMTPS), SSH или IPsec, которые все еще поддерживают RSA, но начали предлагать варианты на основе ECC клиентам, которые их поддерживают. ## 3. WebAuthn: как криптография с открытым ключом используется в ключах доступа? Стандарт WebAuthn — это не стандарт шифрования, а протокол безопасности, который обеспечивает надежную аутентификацию на основе открытого ключа для веб-приложений, позволяя пользователям входить в систему с помощью биометрии, мобильных устройств или аппаратных ключей безопасности (например, YubiKeys) вместо паролей. Поэтому WebAuthn намеренно не привязан к конкретной криптографии на основе открытого ключа. Давайте посмотрим, как это достигается. Протокол безопасности WebAuthn обеспечивает криптографически защищенную аутентификацию между **пользователем** и **доверяющей стороной**. С технической точки зрения это означает, что доверяющая сторона (веб-сайт, который хочет использовать ключи доступа со своими пользователями) должна обмениваться ключами через браузер с пользователем и его аутентификатором, который затем сохраняет закрытый ключ в специальном аппаратном модуле безопасности (HSM). **Для регистрации ключей доступа есть три важных шага:** ![Passkey Registration Process](https://www.corbado.com/website-assets/passkey_registration_process_f27bc263ad.png) - **(1) Доверяющая сторона сообщает о поддерживаемых алгоритмах шифрования:** Доверяющая сторона сообщает о поддерживаемых алгоритмах шифрования через `PublicKeyCredentialCreationOptions.pubKeyCredParams` вместе с другими` PublicKeyCredentialCreationOptions`. - **(2) Аутентификатор пользователя создает пару ключей**: Аутентификатор проверяет список `pubKeyCredParams` на наличие поддерживаемых им алгоритмов шифрования и создает пару ключей вместе с уникальным [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle). Он сохраняет закрытый ключ в HSM, а затем возвращает открытый ключ и использованный алгоритм шифрования в браузер. Затем браузер отправляет POST-запрос на бэкенд доверяющей стороны с `attestationObject` в разделе «authData». **Если поддерживаемые алгоритмы шифрования не совпадают, процедура создания завершится неудачей.** - **(3) Доверяющая сторона извлекает открытый ключ и сохраняет его:** Доверяющая сторона получает `attestationObject` от браузера. Она анализирует раздел `authData.credentialPublicKey` и извлекает открытый ключ. Вместе с открытым ключом доверяющей стороне также отправляется информация об использованном алгоритме шифрования и [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle). **Для последующего входа / аутентификации с помощью ключей доступа необходимы следующие шаги (детали упрощены):** ![Passkey Authentication Process](https://www.corbado.com/website-assets/passkey_authentication_process_5d7c0b9320.png) - **(1) Доверяющая сторона представляет вызов (challenge):** Доверяющая сторона генерирует случайный вызов и предоставляет его аутентификатору для подписи. - **(2) Аутентификатор пользователя подписывает вызов:** Аутентификатор подписывает вызов ключом, соответствующим запросу на аутентификацию, и возвращает его вместе с Credential ID доверяющей стороне. - **(3) Доверяющая сторона проверяет подпись:** Доверяющая сторона получает информацию и находит открытый ключ, связанный с использованным [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle). Затем она криптографически проверяет подпись, используя алгоритм шифрования/подписи, согласованный при регистрации ключей доступа. Рассматривая оба случая, мы видим, что **информация об открытом ключе и алгоритме шифрования передается между участниками только при регистрации ключей доступа.** При последующих входах / аутентификациях с помощью ключей доступа передаются только вызов и подпись. Стандарт WebAuthn использует [идентификаторы алгоритмов IANA COSE](https://www.iana.org/assignments/cose/cose.xhtml) для идентификации используемых алгоритмов шифрования. **Идентификаторы алгоритмов COSE используются как для сообщения о поддерживаемых алгоритмах в pubKeyCredParams, так и для передачи типа фактически созданной пары ключей в credentialPublicKey.** Мы сосредоточимся на их реализации в следующих двух разделах. ## 4. Как выбрать правильные настройки pubKeyCredParams? Список алгоритмов [COSE](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) от IANA включает более 75 алгоритмов, которые теоретически могут быть использованы со стандартом WebAuthn. Большинство алгоритмов с отрицательным ID являются асимметричными с открытым ключом, а большинство с положительным — симметричными, но это скорее условность, так как есть исключения. ### 4.1 Какие алгоритмы COSE актуальны для WebAuthn? Как мы уже отмечали, **алгоритм шифрования должен поддерживаться как аутентификатором, так и бэкендом доверяющей стороны**, чтобы его можно было использовать в процедуре WebAuthn. Поскольку большинство доверяющих сторон используют существующие библиотеки WebAuthn, имеющие доступ к широкому спектру алгоритмов шифрования, важнее посмотреть, какие алгоритмы поддерживаются какими аутентификаторами: | **Название** | **ID** | **Описание** | **Apple** | **Android** | **Windows 10** | **Windows 11+** | **Ключи безопасности** | | ------------ | ------ | ------------------------------------------------ | --------- | ----------- | -------------- | --------------- | ---------------------- | | RS256 | -257 | RSASSA-PKCS1-v1_5 с использованием SHA-256 | ❌ | ❌ | ✅ | ✅ | ✅ | | EdDSA | -8 | EdDSA | ❌ | ❌ | ❌ | ❌ | ✅ (\*) | | ES256 | -7 | ECDSA с SHA-256 (также известный как NIST P-256) | ✅ | ✅ | ❌ | ✅ | ✅ | (\*) = Небольшая часть ключей безопасности (например, Yubikeys 5+, Solokey или Nitrokey) Выдержка из таблицы IANA: Полный список смотрите [здесь](https://www.iana.org/assignments/cose/cose.xhtml) Как видно из этой таблицы, для поддержки всех важных аутентификаторов достаточно RS256 и ES256. Некоторые представители сообщества рекомендуют также интегрировать EdDSA для дальнейшего повышения безопасности. С другой стороны, Credential ID, которые также необходимо хранить, для ключей EdDSA, по-видимому, [значительно длиннее](https://github.com/kanidm/webauthn-rs/discussions/406#discussioncomment-8089897). На сегодняшний день [редакторский черновик W3C предстоящего стандарта WebAuthn уровня 3 предлагает все три алгоритма](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-pubkeycredparams). ### 4.2 Определение массива pubKeyCredParams Настройка поддерживаемых алгоритмов шифрования для создания ключа доступа выполняется через ` PublicKeyCredentialCreationOptions`: ```javascript const publicKeyCredentialCreationOptions = { challenge: "*", rp: { name: "Corbado", id: "corbado.com", }, user: { id: "user-X", name: "user@corbado.com", displayName: "Corbado Name", }, pubKeyCredParams: [ { alg: -8, type: "public-key", }, { alg: -7, type: "public-key", }, { alg: -257, type: "public-key", }, ], authenticatorSelection: { authenticatorAttachment: "platform", requireResidentKey: true, }, }; const credential = await navigator.credentials.create({ publicKey: publicKeyCredentialCreationOptions, }); ``` Пример показывает, как алгоритмы указываются в `pubKeyCredParams`: `alg` для ID и `public-key` в качестве типа алгоритма. В строках 29/30 [PublicKeyCredentialCreationOptions](https://www.corbado.com/glossary/publickeycredentialcreationoptions) передаются аутентификатору через WebAuthn API браузера. Отключение поддержки ES256 или RS256 приведет к ошибкам и категорически не рекомендуется. ![Windows Passkeys Something Went Wrong](https://www.corbado.com/website-assets/windows_passkeys_something_went_wrong_7ddb1bad11.png) В качестве рабочего примера мы запустим следующие `PublicKeyCredentialCreationOptions` на [Mac](https://www.corbado.com/ru/blog/parallels-passkeys-cda) в [Passkeys Debugger](https://www.passkeys-debugger.io/). ```json { "rp": { "id": "www.passkeys-debugger.io", "name": "Relying Party Name" }, "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "pubKeyCredParams": [ { "type": "public-key", "alg": -8 }, { "type": "public-key", "alg": -7 }, { "type": "public-key", "alg": -257 } ], "excludeCredentials": [], "timeout": 120000, "authenticatorSelection": { "residentKey": "required", "requireResidentKey": true, "userVerification": "required", "authenticatorAttachment": "platform" }, "hints": [], "attestation": "direct", "user": { "name": "User-2024-08-19", "displayName": "User-2024-08-19", "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk" } } ``` Ответ, сгенерированный аутентификатором, отправляется доверяющей стороне (в виде аттестации) и выглядит следующим образом: ```json { "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg", "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg", "type": "public-key", "response": { "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c", "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ", "transports": ["internal"], "publicKeyAlgorithm": -7 }, "authenticatorAttachment": "platform", "clientExtensionResults": {} } ``` В следующем разделе мы увидим, как можно извлечь открытые ключи и использованный алгоритм шифрования из ответа. ## 5. Как извлечь открытый ключ из attestationObject? Прежде всего, нам нужно изучить, как устроен `attestationObject`, потому что, как мы видели выше, он передается доверяющей стороне не в формате JSON. ### 5.1 Обзор: что такое attestationObject? **attestationObject** играет важную роль в процессе регистрации WebAuthn, служа контейнером для заявления об аттестации, предоставляемого аутентификатором. Этот объект предоставляет много информации, необходимой доверяющей стороне (RP) для проверки происхождения и целостности вновь созданных учетных данных с открытым ключом. По своей сути **attestationObject** — это сложная структура. В основном он закодирован в формате [CBOR](https://www.corbado.com/glossary/cbor) (Concise Binary Object Representation), который затем кодируется с помощью Base64URL. Он инкапсулирует данные аутентификатора вместе с заявлением об аттестации, которое подтверждает подлинность информации. Поскольку ключи доступа создаются с аттестацией «none» и, следовательно, не содержат заявления об аттестации, мы не будем рассматривать это в данной статье. К слову: мы написали «в основном [CBOR](https://www.corbado.com/glossary/cbor)», потому что из-за переменных длин, необходимых для необязательных расширений, также используются нестандартные префиксы [CBOR](https://www.corbado.com/glossary/cbor). Мы не будем углубляться в это, обсуждение сложностей можно найти [здесь](https://github.com/w3c/webauthn/issues/1614). ![WebAuthn Attestation Object](https://www.corbado.com/website-assets/webauthn_attestation_object_ee7d5216e4.png)_Взято из спецификации WebAuthn_ В данных аутентификатора (**authData**) надежно хранятся вновь сгенерированный открытый ключ и Credential ID пользователя, которые могут быть извлечены доверяющей стороной. Поскольку разработчики должны решать задачу извлечения открытого ключа из **attestationObject** в любой системе на основе WebAuthn, важно понимать его архитектуру. ### 5.2 Что такое Concise Binary Object Representation (CBOR)? CBOR (Concise Binary Object Representation) — это формат данных, предназначенный для компактного, эффективного и расширяемого кодирования данных. Он является двоичным, что делает его меньше и быстрее для анализа, чем его текстовый аналог JSON. Следующий пример иллюстрирует разницу между JSON и CBOR (текст против двоичных данных): | **Текст JSON** | **Двоичные данные CBOR** | **Декодированный CBOR** | | ------------------ | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Name**:_Corbado_ | A1 64 **4E 61 6D 65** 67 _43 6F 72 62 61 64 6F_ | A1 # map(1) с одной записью
64 # text(4)
**4E616D65** # **Name**;
67 # text(7)
_436F726261646F_ # _Corbado_ | **Жирным** выделено Name. _Курсивом_ — Corbado. (больше информации можно найти на [https://cbor.io/](https://cbor.io/)) В контексте WebAuthn CBOR используется по нескольким причинам: - **Связь с FIDO2 / CTAP:** Поскольку CBOR используется в базовых стандартах, достигается оптимизация анализа и обработки данных, так как и WebAuthn, и [CTAP](https://www.corbado.com/ru/glossary/ctap) используют одну и ту же компактную схему кодирования. - **Компактность:** Эффективное кодирование CBOR делает его отличным выбором для веб-трафика, где минимизация размера данных может значительно повлиять на производительность, особенно в мобильных сетях или в средах с ограниченной пропускной способностью. - **Гибкость:** CBOR поддерживает различные типы данных и структуры, включая массивы, карты, текстовые строки, байтовые строки и теги для расширяемости. Это делает его достаточно универсальным для обработки различных типов данных и сложных структур, необходимых для операций WebAuthn. - **Расширяемость:** Формат спроектирован так, чтобы быть расширяемым, что означает, что в WebAuthn можно добавлять новые функции, не нарушая совместимости с существующими реализациями. Использование CBOR особенно подходит для кодирования открытых ключей и **attestationObject**, поскольку ему необходимо обрабатывать различные форматы и длины, которые мы обсуждали выше. Например, ключ RSA будет иметь другие атрибуты и размеры по сравнению с ключом ECDSA. Внутри **attestationObject** открытые ключи хранятся в формате [COSE](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) Key, который основан на CBOR. ### 5.3 Что такое формат COSE Key? Структура [COSE](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) Key построена на объекте-карте CBOR. Она определяет структурированный способ представления ключей, охватывающий различные типы ключей и их соответствующие параметры, такие как модуль и экспонента RSA или координаты открытого ключа эллиптической кривой. Этот стандартизированный формат позволяет сериализовать и десериализовать ключи последовательным образом, независимо от их базового криптографического алгоритма, в дополнение к идентификатору алгоритма шифрования, который мы обсуждали выше. Используя CBOR и формат COSE Key, WebAuthn может обеспечивать широкий спектр криптографических операций, сохраняя при этом полезную нагрузку как можно меньшей и оставаясь адаптируемым к будущим обновлениям в криптографических технологиях. Этот выбор соответствует целям WebAuthn по предоставлению безопасного, эффективного и перспективного протокола для веб-аутентификации. ### 5.4 Декодирование и анализ attestationObject Когда дело доходит до декодирования **attestationObject** в WebAuthn, разработчики сталкиваются с важным решением: разработать собственное решение или использовать устоявшуюся библиотеку. Сложность и критическую важность этого процесса невозможно переоценить. Ручная реализация декодирования Base64URL и CBOR, хотя и технически возможна, несет в себе риск мелких ошибок, которые могут поставить под угрозу целостность процесса аутентификации. Для обеспечения криптографической проверки подписи, а также точности всех других шагов валидации, **настоятельно рекомендуется использовать хорошо протестированную и широко распространенную библиотеку WebAuthn**. Такие библиотеки созданы с учетом экспертных знаний в области шифрования для обработки деталей декодирования и проверки **attestationObject**, включая: - Правильный анализ формата CBOR для извлечения заявления об аттестации и данных аутентификатора. - Интерпретация формата COSE Key для получения открытого ключа. - Выполнение криптографических проверок для валидации подписи в соответствии со стандартом WebAuthn. Полагаясь на авторитетную библиотеку, разработчики не только экономят время и ресурсы, но и обретают уверенность. Открытый ключ, после его извлечения и проверки с помощью этих надежных инструментов, можно безопасно хранить в базе данных, готовый к использованию для безопасных сеансов аутентификации. Такой подход обеспечивает соблюдение спецификаций протокола и поддерживает уровень безопасности, ожидаемый в реализациях WebAuthn. Для простоты мы будем использовать [SimpleWebauthn Debugger](https://debugger.simplewebauthn.dev/?credential=ewogICJpZCI6ICJhV01tRTRCRTlaenZSS2Q5clFoZHk2dWJybEIzQ09yVFJGUUFOZTZ5ZEhnIiwKICAicmF3SWQiOiAiYVdNbUU0QkU5Wnp2UktkOXJRaGR5NnVicmxCM0NPclRSRlFBTmU2eWRIZyIsCiAgInR5cGUiOiAicHVibGljLWtleSIsCiAgInJlc3BvbnNlIjogewogICAgImF0dGVzdGF0aW9uT2JqZWN0IjogIm8yTm1iWFJtY0dGamEyVmtaMkYwZEZOMGJYU2lZMkZzWnlaamMybG5XRWN3UlFJaEFJdlZOQ1RsWVhYN1dLT2ZldG83V3lCUUU2dXZYcHZuTnkyMmtxck14c19RQWlBbWFuRnFhbHJ2RF8xZmUwQ2IyZjYwbGp0aDRubmdja2tLSjhKUHRxWmlPMmhoZFhSb1JHRjBZVmlrdDhER1JUQmZscy1CaE9IMlFDNDA0bHZkaGVfdDJfTmt2TTBuUVdFRUFEZEZBQUFBQUszT0FBSTF2TVlLWklzTEpmSHdWUU1BSUdsakpoT0FSUFdjNzBTbmZhMElYY3VybTY1UWR3anEwMFJVQURYdXNuUjRwUUVDQXlZZ0FTRllJRFA0b25SS1ZIWGxod2JtV0Y0VjZqbWZzdVZ1U1hjaEdtNnhvY2VTQkd0aklsZ2czYnhaSWJLeUU3cVBjek1abVMwakNHQmY5Y2dhanM3N0VaTC1nTkFqTzBjIiwKICAgICJjbGllbnREYXRhSlNPTiI6ICJleUowZVhCbElqb2lkMlZpWVhWMGFHNHVZM0psWVhSbElpd2lZMmhoYkd4bGJtZGxJam9pUVVGQlFtVkNOemhJY2tsbGJXZ3hhbFJrU2tsRGNsOHpVVWRmVWsxUGFIQWlMQ0p2Y21sbmFXNGlPaUpvZEhSd2N6b3ZMMjl3YjNSdmJtNXBaV1V1WjJsMGFIVmlMbWx2SWl3aVkzSnZjM05QY21sbmFXNGlPbVpoYkhObGZRIiwKICAgICJ0cmFuc3BvcnRzIjogWwogICAgICAiaW50ZXJuYWwiCiAgICBdLAogICAgInB1YmxpY0tleUFsZ29yaXRobSI6IC03CiAgfSwKICAiYXV0aGVudGljYXRvckF0dGFjaG1lbnQiOiAicGxhdGZvcm0iLAogICJjbGllbnRFeHRlbnNpb25SZXN1bHRzIjoge30KfQo), который возвращает полностью декодированную версию, где поля CBOR преобразованы в развернутый JSON: ```json { "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg", "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg", "type": "public-key", "response": { "attestationObject": { "fmt": "packed", "attStmt": { "alg": "ES256 (-7)", "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs" }, "authData": { "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc", "flags": { "userPresent": true, "userVerified": true, "backupEligible": false, "backupStatus": false, "attestedData": true, "extensionData": false }, "counter": 0, "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503", "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg", "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c", "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M", "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c" } } }, "clientDataJSON": { "type": "webauthn.create", "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp", "origin": "https://opotonniee.github.io", "crossOrigin": false }, "transports": ["internal"], "publicKeyAlgorithm": -7 }, "authenticatorAttachment": "platform", "clientExtensionResults": {} } ``` Библиотека SimpleWebauthn используется для декодирования всего attestationObject. Как мы видим, вся информация теперь читаема. Вся криптографическая информация является частью `credentialPublicKey`, который, в свою очередь, является частью `authData`. Библиотека развернула его в `parsedCredentialPublicKey`. В спецификации есть несколько примеров того, как выглядит формат COSE Key. ```json { "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M", "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c" } } ``` Этот вывод демонстрирует все криптографические элементы **credentialPublicKey**, аккуратно разобранные в удобочитаемую форму. Этот конкретный экземпляр показывает ключ EC2 для алгоритма ES256, на что указывает параметр алгоритма и наличие координат **x** и **y**. В отличие от этого, вывод системы Windows 10 выглядит следующим образом: ```json { "parsedCredentialPublicKey": { "keyType": "RSA (3)", "algorithm": "RS256 (-257)", "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ", "exponent": 65537 } } ``` Здесь ID алгоритма равен -257, что соответствует RS256, и мы можем заметить, что атрибуты, характеризующие этот открытый ключ, значительно отличаются от атрибутов ключа ECDSA. Формат COSE Key позволяет указывать уникальные атрибуты для каждого типа: | **Атрибут/Тип** | **ECDSA** | **RSA** | | ------------------- | -------------------------------- | ----------------- | | Тип ключа | EC2 (Эллиптическая кривая 2) | RSA (3) | | Алгоритм | ES256 (-7) | RS256 (-257) | | Уникальные атрибуты | Кривая Координата X Координата Y | Модуль Экспонента | Кроме того, модуль RSA значительно длиннее, чем координаты эллиптической кривой, используемые в ключе ES256, что подчеркивает наше предыдущее обсуждение различий в размерах ключей и присущих им требований различных криптографических алгоритмов. ## 6. Рекомендация Рассмотрев основы криптографии с открытым ключом и поняв, как она встроена в стандарт WebAuthn / [FIDO2](https://www.corbado.com/glossary/fido2), у нас есть две основные рекомендации для доверяющих сторон: - **Выбирайте правильные алгоритмы шифрования:** При реализации WebAuthn важно использовать правильные алгоритмы для максимальной совместимости. Основываясь на текущих рекомендациях, целесообразно использовать комбинацию RS256, ES256 и EdDSA. RS256 и ES256 выделяются благодаря своей широкой поддержке, а включение EdDSA может повысить безопасность там, где это возможно. - **Используйте хорошо протестированные библиотеки WebAuthn для извлечения открытого ключа:** После того как вы определились с алгоритмами, следующим шагом является интеграция хорошо протестированной библиотеки WebAuthn. Такая библиотека может грамотно справиться со сложностями анализа _attestationObject_. После того как библиотека извлекла открытые ключи и связанные с ними данные, их можно безопасно сохранить в базе данных. Формат, используемый библиотекой, обычно гарантирует, что ключ хранится таким образом, чтобы его можно было точно прочитать и использовать для будущих целей аутентификации. **Крайне важно не изобретать велосипед:** используйте коллективные знания, заложенные в устоявшихся библиотеках. Собственная реализация рискует внести ошибки и уязвимости в безопасности, которые могут подорвать эффективность аутентификации и общую безопасность системы. ## 7. Заключение В этой статье мы рассмотрели основы криптографии с открытым ключом, чтобы ответить на три первоначальных ключевых вопроса: 1. **Поддерживаемые алгоритмы шифрования в WebAuthn**: WebAuthn спроектирован гибким и поддерживает широкий спектр алгоритмов шифрования, в первую очередь RSA (RS256), ECDSA (ES256) и EdDSA. Эта адаптивность позволяет ему легко интегрироваться с различными аутентификаторами и платформами, обеспечивая широкую совместимость. 2. **Функциональность pubKeyCredParams при создании пары ключей**: **pubKeyCredParams** играют важную роль на этапе регистрации в процессе WebAuthn, указывая, какие криптографические алгоритмы поддерживает доверяющая сторона. Это гарантирует, что созданные пары ключей совместимы как с аутентификатором пользователя, так и с требованиями доверяющей стороны. 3. **Функциональность credentialPublicKey и извлечение открытых ключей**: **credentialPublicKey** используется для извлечения открытых ключей из attestationObject, предоставляемого аутентификаторами. Кроме того, мы подчеркнули независимость протокола WebAuthn от конкретных алгоритмов шифрования, что значительно повышает его гибкость и обеспечивает защиту от будущих криптографических методов. Мы надеемся, что эта статья также поможет другим разработчикам при отладке и понимании концепций / проблем, связанных с криптографией с открытым ключом в WebAuthn.