WebAuthn pubKeyCredParams и credentialPublicKey: CBOR и COSE

В цифровой безопасности ключи доступа (passkeys) — это новый стандарт беспарольной аутентификации. В основе ключей доступа лежит криптография с открытым ключом, используемая в протоколе WebAuthn, на котором они базируются. Понимание того, как криптография с открытым ключом используется в WebAuthn, особенно при создании, извлечении, управлении и хранении ключей доступа, имеет решающее значение при разработке или использовании аутентификации с помощью ключей доступа. Открытый ключ хранится на сервере доверяющей стороны (Relying Party, RP), то есть на бэкенде веб-сайта, который хочет аутентифицировать пользователя с помощью ключей доступа, а закрытый ключ надежно хранится в аппаратном модуле безопасности в зависимости от операционной системы: Secure Enclave (iOS), TEE (Android) или TPM (Windows).

В этой статье мы кратко рассмотрим основы криптографии с открытым ключом, используемой в ключах доступа. К концу статьи мы должны получить ответы на следующие вопросы:

• Какие алгоритмы шифрования поддерживаются в WebAuthn
• Как работают pubKeyCredParams при создании пары ключей?
• Как работает credentialPublicKey при извлечении созданных открытых ключей?

Чтобы понять, как криптография с открытым ключом работает в рамках WebAuthn, мы кратко рассмотрим ее общие принципы и распространенные типы алгоритмов.

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

Взято с: https://en.wikipedia.org/wiki/Public-key_cryptography

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

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Вот обзор некоторых распространенных типов алгоритмов, используемых в криптографии с открытым ключом:

Математическая основа криптографии на эллиптических кривых (ECC), включая ECDSA и EdDSA, связана со свойствами эллиптических кривых, которые мы не будем рассматривать в этой статье. Но из приведенной выше таблицы очевидно, что существуют преимущества, которые способствуют их внедрению. Мы рассмотрим самые важные из них в следующем разделе.

Become part of our Passkeys Community for updates & support.

Join

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

• Снижение требований к хранилищу: Меньшие ключи ECC требуют меньше места для хранения по сравнению с традиционными криптографическими методами, такими как RSA. Это особенно полезно для устройств с ограниченными ресурсами памяти, что позволяет более эффективно использовать пространство. В следующей таблице показано приблизительное соответствие уровней безопасности и фактических размеров используемых ключей. Уровень безопасности измеряется в битах и обычно соответствует симметричному шифру с ключом такого же размера:

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

• Повышенная производительность: Меньшие ключи обеспечивают более быстрые криптографические операции, что крайне важно для устройств с меньшей вычислительной мощностью. Это приводит к ускорению шифрования и дешифрования, повышая общую производительность и отзывчивость мобильных приложений. В зависимости от типа тестов производительности ускорение выполнения может составлять от 10 до 40 раз. Вот пример данных тестирования, которые AWS провела при внедрении ECDSA для Cloudfront в 2018 году:

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

Эти факторы делают ECC особенно подходящей для мобильных сред, где оптимизация хранилища, скорости обработки и энергопотребления имеет важное значение. В результате ECC все чаще предпочитают в мобильных вычислениях за ее способность обеспечивать надежную безопасность без ущерба для производительности устройства. Тем не менее, до сих пор существует множество старых версий распространенных протоколов, таких как TLS (используемый для HTTPS, FTPS или SMTPS), SSH или IPsec, которые все еще поддерживают RSA, но начали предлагать варианты на основе ECC клиентам, которые их поддерживают.

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

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

Для регистрации ключей доступа есть три важных шага:

• (1) Доверяющая сторона сообщает о поддерживаемых алгоритмах шифрования: Доверяющая сторона сообщает о поддерживаемых алгоритмах шифрования через PublicKeyCredentialCreationOptions.pubKeyCredParams вместе с другими PublicKeyCredentialCreationOptions.
• (2) Аутентификатор пользователя создает пару ключей: Аутентификатор проверяет список pubKeyCredParams на наличие поддерживаемых им алгоритмов шифрования и создает пару ключей вместе с уникальным Credential ID. Он сохраняет закрытый ключ в HSM, а затем возвращает открытый ключ и использованный алгоритм шифрования в браузер. Затем браузер отправляет POST-запрос на бэкенд доверяющей стороны с attestationObject в разделе «authData». Если поддерживаемые алгоритмы шифрования не совпадают, процедура создания завершится неудачей.
• (3) Доверяющая сторона извлекает открытый ключ и сохраняет его: Доверяющая сторона получает attestationObject от браузера. Она анализирует раздел authData.credentialPublicKey и извлекает открытый ключ. Вместе с открытым ключом доверяющей стороне также отправляется информация об использованном алгоритме шифрования и Credential ID.

Для последующего входа / аутентификации с помощью ключей доступа необходимы следующие шаги (детали упрощены):

• (1) Доверяющая сторона представляет вызов (challenge): Доверяющая сторона генерирует случайный вызов и предоставляет его аутентификатору для подписи.
• (2) Аутентификатор пользователя подписывает вызов: Аутентификатор подписывает вызов ключом, соответствующим запросу на аутентификацию, и возвращает его вместе с Credential ID доверяющей стороне.
• (3) Доверяющая сторона проверяет подпись: Доверяющая сторона получает информацию и находит открытый ключ, связанный с использованным Credential ID. Затем она криптографически проверяет подпись, используя алгоритм шифрования/подписи, согласованный при регистрации ключей доступа.

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

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

Стандарт WebAuthn использует идентификаторы алгоритмов IANA COSE для идентификации используемых алгоритмов шифрования. Идентификаторы алгоритмов COSE используются как для сообщения о поддерживаемых алгоритмах в pubKeyCredParams, так и для передачи типа фактически созданной пары ключей в credentialPublicKey. Мы сосредоточимся на их реализации в следующих двух разделах.

Список алгоритмов COSE от IANA включает более 75 алгоритмов, которые теоретически могут быть использованы со стандартом WebAuthn. Большинство алгоритмов с отрицательным ID являются асимметричными с открытым ключом, а большинство с положительным — симметричными, но это скорее условность, так как есть исключения.

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

(*) = Небольшая часть ключей безопасности (например, Yubikeys 5+, Solokey или Nitrokey) Выдержка из таблицы IANA: Полный список смотрите здесь

Как видно из этой таблицы, для поддержки всех важных аутентификаторов достаточно RS256 и ES256. Некоторые представители сообщества рекомендуют также интегрировать EdDSA для дальнейшего повышения безопасности. С другой стороны, Credential ID, которые также необходимо хранить, для ключей EdDSA, по-видимому, значительно длиннее. На сегодняшний день редакторский черновик W3C предстоящего стандарта WebAuthn уровня 3 предлагает все три алгоритма.

Настройка поддерживаемых алгоритмов шифрования для создания ключа доступа выполняется через PublicKeyCredentialCreationOptions:

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 передаются аутентификатору через WebAuthn API браузера. Отключение поддержки ES256 или RS256 приведет к ошибкам и категорически не рекомендуется.

В качестве рабочего примера мы запустим следующие PublicKeyCredentialCreationOptions на Mac в Passkeys Debugger.

{
    "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"
    }
}

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

{
    "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": {}
}

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

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

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

По своей сути attestationObject — это сложная структура. В основном он закодирован в формате CBOR (Concise Binary Object Representation), который затем кодируется с помощью Base64URL. Он инкапсулирует данные аутентификатора вместе с заявлением об аттестации, которое подтверждает подлинность информации. Поскольку ключи доступа создаются с аттестацией «none» и, следовательно, не содержат заявления об аттестации, мы не будем рассматривать это в данной статье. К слову: мы написали «в основном CBOR», потому что из-за переменных длин, необходимых для необязательных расширений, также используются нестандартные префиксы CBOR. Мы не будем углубляться в это, обсуждение сложностей можно найти здесь.

Взято из спецификации WebAuthn

В данных аутентификатора (authData) надежно хранятся вновь сгенерированный открытый ключ и Credential ID пользователя, которые могут быть извлечены доверяющей стороной. Поскольку разработчики должны решать задачу извлечения открытого ключа из attestationObject в любой системе на основе WebAuthn, важно понимать его архитектуру.

CBOR (Concise Binary Object Representation) — это формат данных, предназначенный для компактного, эффективного и расширяемого кодирования данных. Он является двоичным, что делает его меньше и быстрее для анализа, чем его текстовый аналог JSON. Следующий пример иллюстрирует разницу между JSON и CBOR (текст против двоичных данных):

Жирным выделено Name. Курсивом — Corbado. (больше информации можно найти на https://cbor.io/)

В контексте WebAuthn CBOR используется по нескольким причинам:

• Связь с FIDO2 / CTAP: Поскольку CBOR используется в базовых стандартах, достигается оптимизация анализа и обработки данных, так как и WebAuthn, и CTAP используют одну и ту же компактную схему кодирования.
• Компактность: Эффективное кодирование CBOR делает его отличным выбором для веб-трафика, где минимизация размера данных может значительно повлиять на производительность, особенно в мобильных сетях или в средах с ограниченной пропускной способностью.
• Гибкость: CBOR поддерживает различные типы данных и структуры, включая массивы, карты, текстовые строки, байтовые строки и теги для расширяемости. Это делает его достаточно универсальным для обработки различных типов данных и сложных структур, необходимых для операций WebAuthn.
• Расширяемость: Формат спроектирован так, чтобы быть расширяемым, что означает, что в WebAuthn можно добавлять новые функции, не нарушая совместимости с существующими реализациями.

Использование CBOR особенно подходит для кодирования открытых ключей и attestationObject, поскольку ему необходимо обрабатывать различные форматы и длины, которые мы обсуждали выше. Например, ключ RSA будет иметь другие атрибуты и размеры по сравнению с ключом ECDSA. Внутри attestationObject открытые ключи хранятся в формате COSE Key, который основан на CBOR.

Структура COSE Key построена на объекте-карте CBOR. Она определяет структурированный способ представления ключей, охватывающий различные типы ключей и их соответствующие параметры, такие как модуль и экспонента RSA или координаты открытого ключа эллиптической кривой. Этот стандартизированный формат позволяет сериализовать и десериализовать ключи последовательным образом, независимо от их базового криптографического алгоритма, в дополнение к идентификатору алгоритма шифрования, который мы обсуждали выше.

Используя CBOR и формат COSE Key, WebAuthn может обеспечивать широкий спектр криптографических операций, сохраняя при этом полезную нагрузку как можно меньшей и оставаясь адаптируемым к будущим обновлениям в криптографических технологиях. Этот выбор соответствует целям WebAuthn по предоставлению безопасного, эффективного и перспективного протокола для веб-аутентификации.

Когда дело доходит до декодирования attestationObject в WebAuthn, разработчики сталкиваются с важным решением: разработать собственное решение или использовать устоявшуюся библиотеку. Сложность и критическую важность этого процесса невозможно переоценить. Ручная реализация декодирования Base64URL и CBOR, хотя и технически возможна, несет в себе риск мелких ошибок, которые могут поставить под угрозу целостность процесса аутентификации.

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

• Правильный анализ формата CBOR для извлечения заявления об аттестации и данных аутентификатора.
• Интерпретация формата COSE Key для получения открытого ключа.
• Выполнение криптографических проверок для валидации подписи в соответствии со стандартом WebAuthn.

Полагаясь на авторитетную библиотеку, разработчики не только экономят время и ресурсы, но и обретают уверенность. Открытый ключ, после его извлечения и проверки с помощью этих надежных инструментов, можно безопасно хранить в базе данных, готовый к использованию для безопасных сеансов аутентификации. Такой подход обеспечивает соблюдение спецификаций протокола и поддерживает уровень безопасности, ожидаемый в реализациях WebAuthn. Для простоты мы будем использовать SimpleWebauthn Debugger, который возвращает полностью декодированную версию, где поля CBOR преобразованы в развернутый 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.

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

Этот вывод демонстрирует все криптографические элементы credentialPublicKey, аккуратно разобранные в удобочитаемую форму. Этот конкретный экземпляр показывает ключ EC2 для алгоритма ES256, на что указывает параметр алгоритма и наличие координат x и y.

В отличие от этого, вывод системы Windows 10 выглядит следующим образом:

{
    "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 позволяет указывать уникальные атрибуты для каждого типа:

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

Рассмотрев основы криптографии с открытым ключом и поняв, как она встроена в стандарт WebAuthn / FIDO2, у нас есть две основные рекомендации для доверяющих сторон:

• Выбирайте правильные алгоритмы шифрования: При реализации WebAuthn важно использовать правильные алгоритмы для максимальной совместимости. Основываясь на текущих рекомендациях, целесообразно использовать комбинацию RS256, ES256 и EdDSA. RS256 и ES256 выделяются благодаря своей широкой поддержке, а включение EdDSA может повысить безопасность там, где это возможно.
• Используйте хорошо протестированные библиотеки WebAuthn для извлечения открытого ключа: После того как вы определились с алгоритмами, следующим шагом является интеграция хорошо протестированной библиотеки WebAuthn. Такая библиотека может грамотно справиться со сложностями анализа attestationObject. После того как библиотека извлекла открытые ключи и связанные с ними данные, их можно безопасно сохранить в базе данных. Формат, используемый библиотекой, обычно гарантирует, что ключ хранится таким образом, чтобы его можно было точно прочитать и использовать для будущих целей аутентификации.

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

В этой статье мы рассмотрели основы криптографии с открытым ключом, чтобы ответить на три первоначальных ключевых вопроса:

1. Поддерживаемые алгоритмы шифрования в WebAuthn: WebAuthn спроектирован гибким и поддерживает широкий спектр алгоритмов шифрования, в первую очередь RSA (RS256), ECDSA (ES256) и EdDSA. Эта адаптивность позволяет ему легко интегрироваться с различными аутентификаторами и платформами, обеспечивая широкую совместимость.
2. Функциональность pubKeyCredParams при создании пары ключей: pubKeyCredParams играют важную роль на этапе регистрации в процессе WebAuthn, указывая, какие криптографические алгоритмы поддерживает доверяющая сторона. Это гарантирует, что созданные пары ключей совместимы как с аутентификатором пользователя, так и с требованиями доверяющей стороны.
3. Функциональность credentialPublicKey и извлечение открытых ключей: credentialPublicKey используется для извлечения открытых ключей из attestationObject, предоставляемого аутентификаторами.

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