---
url: 'https://www.corbado.com/ru/blog/device-bound-synced-passkeys'
title: 'Аппаратно-привязанные и синхронизируемые ключи доступа (SCA и ключи доступа I)'
description: 'Узнайте о синхронизируемых и аппаратно-привязанных ключах доступа, их отличиях и роли аппаратных модулей безопасности (Secure Enclave, TEE, TPM).'
lang: 'ru'
author: 'Vincent Delitz'
date: '2026-05-24T16:30:29.271Z'
lastModified: '2026-05-24T16:35:30.713Z'
keywords: 'аппаратно-привязанные ключи доступа, синхронизируемые ключи доступа, устройство для ключей доступа, device-bound passkey, synced passkey'
category: 'Passkeys Strategy'
---

# Аппаратно-привязанные и синхронизируемые ключи доступа (SCA и ключи доступа I)

## Обзор: строгая аутентификация клиентов с использованием ключей доступа

- Анализ требований PSD2 и SCA
- Что требования SCA означают для ключей доступа
- Последствия PSD3 / PSR для ключей доступа

## 1. Введение: аппаратно-привязанные и синхронизируемые ключи доступа

В нашей предыдущей статье о ключах доступа и PSD2 мы обсуждали, как ключи доступа уже используются такими финтех-компаниями, как Revolut и Finom, и как они повышают цифровую безопасность [банковского сектора](https://www.corbado.com/passkeys-for-banking).

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

В этой серии из четырех статей мы хотим подробно проанализировать, как различные типы ключей доступа (аппаратно-привязанные и синхронизируемые) соответствуют требованиям SCA и PSD2.

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

Вторая часть доступно объясняет, что такое PSD2 и строгая аутентификация клиентов (SCA), в том числе путем изложения истории их развития.

В третьей части серии показано, как различные типы ключей доступа соответствуют требованиям SCA, и что это означает для банков, финтех-компаний и финансовых учреждений, которые планируют внедрять ключи доступа.

Четвертая и заключительная часть серии подводит итоги того, что PSD3 / PSR будут означать для SCA и ключей доступа в будущем.

## 2. Строгая аутентификация клиентов, PSD2 и ключи доступа

После публикации нашей последней статьи мы получили множество вопросов относительно нашей позиции по ключам доступа, особенно в связи с SCA в рамках концепции PSD2. Существует явный интерес к пониманию не только применения ключей доступа, но и того, как они соответствуют **Регуляторным техническим стандартам (RTS)**. Кроме того, заинтересованным сторонам интересно узнать о потенциальных трактовках и рекомендациях от регуляторов, включая **Европейское банковское управление (EBA)**, по использованию ключей доступа.

Осознавая это, мы стремимся глубже изучить, как ключи доступа могут быть интегрированы в директиву PSD2 и RTS по SCA, и прояснить нашу позицию относительно использования этой технологии. Мы также рассмотрим существующие вопросы и ответы EBA, чтобы пролить свет на то, как регуляторы и EBA могут воспринимать ключи доступа. Это исследование не только затронет различия между синхронизируемыми и аппаратно-привязанными ключами доступа, но и их практическое применение для повышения как безопасности, так и удобства пользователей.

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

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

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

[Watch on YouTube](https://www.youtube.com/watch?v=V1Pc4Gl0xKc)

## 3. От аппаратно-привязанных ключей доступа к синхронизируемым

Чтобы понять различия между аппаратно-привязанными и синхронизируемыми ключами доступа, мы кратко рассмотрим, как развивалась экосистема.

### 3.1 Что такое аппаратно-привязанные ключи доступа (ключи доступа для одного устройства)?

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

![Аппаратно-привязанный ключ доступа](https://www.corbado.com/website-assets/device_bound_passkey_effe25ab99.png)

#### 3.1.1 История аппаратно-привязанных ключей доступа

Исторически механизмы аутентификации в рамках WebAuthn (стандарта, лежащего в основе ключей доступа) были тесно связаны с физическими устройствами: ключами безопасности (например, YubiKeys). До широкого внедрения ключей доступа [учетные данные FIDO2, привязанные к одному аутентификатору, представляли собой золотой стандарт](https://github.com/w3c/webauthn/wiki/Explainer:-broadening-the-user-base-of-WebAuthn) безопасности. Эти учетные данные связаны с устройством, на котором они находятся. Значение этой привязки было существенным: учетные данные нельзя было передать или использовать за пределами оригинального оборудования.

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

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

#### 3.1.2 Технические детали аппаратно-привязанных ключей доступа

**Аппаратно-привязанные ключи доступа** характеризуются своей специфической категоризацией на обнаруживаемые и необнаруживаемые учетные данные, при этом различие в первую очередь определяет их обнаруживаемость. Но ключевой фактор, отличающий **аппаратно-привязанные ключи**, заложен в свойствах учетных данных WebAuthn, в частности, через флаги `isBackupEligible` и `isBackupSynchronized`. Для **аппаратно-привязанных ключей доступа** оба этих поля установлены в ноль, что указывает на то, что учетные данные не подлежат резервному копированию или синхронизации между устройствами. Эти характеристики подчеркивают их внутреннюю связь с физическим устройством, на котором они были созданы, гарантируя, что учетные данные остаются привязанными к этому конкретному аппаратному обеспечению и могут использоваться только на нем.

Заметный пример аппаратно-привязанных учетных данных на практике наблюдается в экосистеме Windows. Учетные данные Windows Hello в Windows 10 и Windows 11 остаются аппаратно-привязанными — сама по себе Windows Hello пока не синхронизирует ключи доступа между устройствами. Однако Microsoft сделала значительный первый шаг, [внедрив сохранение и синхронизацию ключей доступа в Microsoft Edge](https://blogs.windows.com/msedgedev/2025/11/03/microsoft-edge-introduces-passkey-saving-and-syncing-with-microsoft-password-manager/) (начиная с Edge 142). Эта синхронизация на уровне браузера через Microsoft Password Manager позволяет ключам доступа синхронизироваться между устройствами Windows при использовании Edge, подобно тому, как Google Password Manager обеспечивает синхронизацию ключей доступа в браузере Chrome на Windows. Это представляет собой важное достижение в возможностях ключей доступа Windows, хотя оно специфично для браузера Edge, а не для платформенного аутентификатора Windows Hello. Ключи доступа Windows Hello остаются аппаратно-привязанными, но эта интеграция Edge обеспечивает практический путь к синхронизируемым ключам доступа в Windows, в то время как сам платформенный аутентификатор может в будущем развиваться для поддержки синхронизации.

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

В отличие от этого, подход Apple к macOS и iOS существенно отличается. В отличие от фиксированной, аппаратно-привязанной стратегии, наблюдаемой в Windows и необнаруживаемых ключах Google, [экосистема Apple гораздо сильнее склоняется к разрешению только синхронизируемых ключей доступа, особенно на iOS](https://fy.blackhats.net.au/blog/2023-02-02-how-hype-will-turn-your-security-key-into-junk/), что делает невозможным создание аппаратно-привязанного ключа доступа через WebAuthn.

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

### 3.2 Что такое синхронизируемые ключи доступа (ключи доступа для нескольких устройств)?

Здесь мы также рассмотрим историческое развитие синхронизируемых ключей доступа, прежде чем анализировать технические детали. Иногда синхронизируемые ключи доступа также называют **синхронизируемыми ключами (syncable passkeys)**.

![Синхронизируемый ключ доступа](https://www.corbado.com/website-assets/synced_passkey_042125aca6.png)

#### 3.2.1 История синхронизируемых ключей доступа

После публикации спецификаций WebAuthn Level 2 и CTAP 2.1 в середине-конце 2021 года рабочая группа WebAuthn запустила значительную отраслевую инициативу, направленную на преодоление основных препятствий, мешающих стандарту WebAuthn заменить пароли и увеличить уровень внедрения. Эта инициатива была сосредоточена на двух критически важных областях: устранение требования к дополнительным аппаратным устройствам безопасности и снижение риска, связанного с потерей аутентификатора, при сохранении полной обратной совместимости с существующими стандартами.

##### 3.2.1.1 Использование платформенных аутентификаторов в качестве безопасных аппаратных модулей

Первая проблема — искоренение потребности в новом оборудовании — была решена за счет использования встроенных платформенных аутентификаторов, которые можно найти в современных потребительских устройствах (например, Touch ID, Face ID, Windows Hello).

![Аппаратные модули безопасности HSM TPM TEE Secure Enclave](https://www.corbado.com/website-assets/hardware_security_modules_hsm_tpm_tee_secure_enclave_11118d359e.png)

Современные устройства все чаще оснащаются специализированными модулями безопасности, такими как Trusted Execution Environment (TEE) на Android, Secure Enclave на iOS и macOS и Trusted Platform Module (TPM) на устройствах Windows. Эти встроенные хранилища ключей безопасности служат надежной основой для ключей доступа, эффективно функционируя как встроенные «ключи безопасности». Этот подход позволяет широко внедрять криптографию с открытым ключом, уровень безопасности, ранее достижимый только с помощью внешних аппаратных ключей безопасности (например, YubiKeys) и в значительной степени ограниченный технически подкованными лицами или организациями в жестко регулируемых отраслях.

Используя возможности TEE, Secure Enclave или TPM, протоколы WebAuthn получают возможность предоставлять надежные криптографические механизмы аутентификации пользователей. Теперь сложные методы аутентификации стали удобными и доступными для широкой публики без необходимости в дополнительном специализированном оборудовании.

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

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

##### 3.2.1.2 Синхронизация ключей доступа в облако

Чтобы снизить риск, связанный с потерей мобильного телефона и, как следствие, хранящихся на нем ключей доступа, отраслевая инициатива была сосредоточена на обеспечении возможности синхронизации обнаруживаемых учетных данных с облаком. Этот подход эффективно преобразовал учетные данные из строго привязанных к устройству в данные для нескольких устройств и, точнее, привязанные к учетной записи пользователя у его облачного провайдера, такого как iCloud для устройств Apple или Google для устройств Android.

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

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

Этот переход к синхронизируемым через облако учетным данным, привязанным к аккаунту, представляет собой прагматичный подход к цифровой безопасности. Он признает реалии современного использования устройств и частое возникновение ситуаций замены устройств, будь то из-за потери, повреждения или обновления. Привязывая учетные данные к облачной учетной записи пользователя — будь то iCloud от Apple или облачные сервисы Google — решение не только снижает риск, связанный с потерей устройства, но и расширяет возможности пользователя по управлению и восстановлению своей цифровой идентичности на нескольких устройствах.

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

#### 3.2.2 Технические детали синхронизируемых ключей доступа

Синхронизируемые ключи доступа также известны как обнаруживаемые учетные данные или резидентные ключи (resident keys). Они отличаются от аппаратно-привязанных ключей двумя критически важными свойствами: `isBackupEligible` и `isBackedUp` имеют разные значения. Для синхронизируемых ключей доступа флаг `isBackupEligible` установлен в 1, что указывает на то, что эти учетные данные подлежат резервному копированию. После успешной синхронизации с облаком флаг `isBackedUp` также устанавливается в 1, подтверждая, что учетные данные были должным образом синхронизированы. Важно отметить, что статус синхронизации может меняться со временем, отражая динамичный характер использования устройств и управления ими.

Когда платформы запрашивают резидентные ключи, устанавливая параметр "requireResidentKey" в значение **required** или **preferred**, платформы, поддерживающие облачные сервисы, автоматически создают синхронизируемые ключи доступа. Этот процесс гарантирует, что пользователи могут рассчитывать на доступность своих учетных данных на различных устройствах. В Windows синхронизируемые ключи доступа теперь доступны через Microsoft Edge / Microsoft Password Manager (синхронизация на уровне браузера), в то время как учетные данные платформенного аутентификатора Windows Hello остаются аппаратно-привязанными. Сторонние менеджеры паролей (например, Dashlane, KeePassXC, 1Password) с возможностями управления ключами доступа также обеспечивают синхронизацию на разных платформах. В сценариях, где используются синхронизируемые ключи доступа, флаги `isBackupEligible` и `isBackedUp` устанавливаются в 1, указывая на правомочность резервного копирования и успешную синхронизацию.

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

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

### 3.3 Привязка учетных данных WebAuthn к одному устройству, принесенная в жертву высшему благу

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

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

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

Обсуждение пришло к выводу, что должна быть гармонизация интересов, но в первую очередь высшее благо распространения ключей доступа должно иметь приоритет. В ходе обсуждения расширение [devicePubKey](https://github.com/w3c/webauthn/issues/1658) рассматривалось как один из способов решения этих проблем, но позже было заменено на **supplementalPubKeys**, которые применяют гораздо более широкий подход к текущему проекту WebAuthn Level 3. К сожалению, разработка этого подхода также была прекращена в августе 2024 года.

### 3.4 Лучшее из двух миров: ключи доступа и расширение supplementalPubKeys \[устарело с августа 2024 года]

Давайте проанализируем, как был сформирован компромисс с расширением supplementalPubKeys, и что это означает технически.

#### 3.4.1 От расширения devicePubKey к supplementalPubKeys

Дискуссия вокруг перехода от расширения **devicePubKey** к расширению **supplementalPubKeys** подчеркивает динамичный характер спецификации WebAuthn. Изначально **devicePubKey** служило для повышения безопасности с помощью аппаратно-привязанных открытых ключей, но позже оно было заменено предложением **supplementalPubKeys** в [рабочем проекте редактора WebAuthn Level 3](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension). Это новое расширение предлагает более комплексное решение, позволяя использовать несколько ключей для улучшения процессов аутентификации.

Суть дебатов сводилась к поиску баланса между усиленными мерами безопасности и более широким внедрением и практической полезностью ключей доступа на различных устройствах и платформах. Расширение **supplementalPubKeys** представляет собой комбинацию этих приоритетов, обеспечивая более строгую аутентификацию. Например, оно учитывает правила, требующие соблюдения определенных стандартов аутентификации, разрешая дополнительные «подотчетные ключи» с заявлениями об аттестации. Эти ключи могут сигнализировать о соответствии требованиям аутентификации, что потенциально снижает потребность в дополнительных проверках при входе в систему при определенных условиях (даже при использовании ключей доступа).

[Пример непосредственно из черновика WebAuthn](https://w3c.github.io/webauthn/#sctn-supplemental-public-keys-extension):

«_Допустим, на веб-сайт поступает запрос на вход вместе с неким геолокационным сигналом, который ранее не наблюдался для этой учетной записи пользователя, и вне типичных часов использования, наблюдаемых для этой учетной записи. Риск может быть признан достаточно высоким, чтобы не разрешать запрос, даже при подтверждении учетными данными для нескольких устройств самостоятельно. Но если также может быть представлена подпись от дополнительного ключа, который привязан к устройству и который хорошо зарекомендовал себя для этого пользователя, то это может склонить чашу весов._»

Во время обсуждения было подчеркнуто, что они предназначены только для RP с чрезвычайно высокими требованиями к безопасности (например, в [государственном](https://www.corbado.com/passkeys-for-public-sector) секторе).

Учитывая отзывы и рассматривая конкретные сценарии использования — включая регулируемые финансовые транзакции и необходимость в аппаратно-привязанных сигналах в среде учетных данных для нескольких устройств — сообщество WebAuthn стремилось решить как проблемы безопасности, так и совместимости. Таким образом, расширение **supplementalPubKeys** представляет собой подход, который направлен на обеспечение надежных функций безопасности при поддержке бесперебойного пользовательского опыта и широкой совместимости, необходимых для повсеместного внедрения ключей доступа. Это совершенно необязательное расширение, которое не мешает внедрению ключей доступа, которое уже наблюдалось в последние 2 года.

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

#### 3.4.2 Технические детали supplementalPubKeys

Расширение **supplementalPubKeys**, представленное в WebAuthn, позволяет использовать дополнительные пары ключей наряду с основными учетными данными.

![График дополнительных открытых ключей](https://www.corbado.com/website-assets/supplemental_pub_key_chart_b976bf5115.png)_Взято из оригинального [обсуждения на GitHub](https://github.com/w3c/webauthn/pull/1957)_

На изображении показана концепция **supplementalPubKey**, взятая из оригинального [обсуждения на GitHub](https://github.com/w3c/webauthn/pull/1957) (pk = ключ доступа (passkey), pspk = дополнительный ключ провайдера (provider supplemental key), dspk = дополнительный ключ устройства (device supplemental key)).

Вот разбивка того, как это работает, и предполагаемое использование:

**Назначение и функциональность supplementalPubKey**

- **Остаются одни центральные учетные данные ключа доступа:** важно помнить, что только один центральный ключ доступа остается основным методом аутентификации пользователя, а дополнительные ключи обеспечивают дополнительные уровни безопасности и гарантий. Эта структура поддерживает простоту и эффективность использования единого основного ключа доступа для аутентификации на нескольких устройствах, обеспечивая бесперебойный пользовательский опыт. Тем временем дополнительные ключи служат для расширения контекста аутентификации, предлагая проверяющей стороне (Relying Party) дополнительные сигналы о среде безопасности или соответствии конкретным стандартам аутентификации. Эти дополнительные ключи не являются автономными методами аутентификации, а скорее дополняют основной ключ доступа, подкрепляя его надежность доказательствами целостности устройства
- **Аппаратно-привязанные ключи**: они привязаны конкретно к одному устройству. Они могут предоставить гарантии того, что запрос на аутентификацию поступает от доверенного устройства, которое ранее было аутентифицировано. Они ни при каких обстоятельствах не будут синхронизированы.
- **Ключи, привязанные к провайдеру**: эти ключи имеют область действия "провайдера", что означает, что они могут предоставлять дополнительные гарантии на основе политик провайдера аутентификации или конкретной аттестации провайдера. Например, провайдер может выдавать такой ключ только после того, как пользователь пройдет более высокий уровень аутентификации (например, 2FA).
- **Несколько открытых ключей**: в отличие от своего предшественника, расширения **devicePubKey**, которое допускало только один аппаратно-привязанный открытый ключ, **supplementalPubKeys** позволяет включать один или два типа дополнительных ключей. Эти ключи могут служить разным целям и областям применения, а именно: области применения, привязанной к устройству, и области применения, привязанной к провайдеру.

**Сценарии использования и примеры supplementalPubKey**

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

**Технические аспекты supplementalPubKey**

- **Отсутствие собственного идентификатора учетных данных (Credential ID):** дополнительные ключи не являются учетными данными пользователя и не имеют собственных идентификаторов учетных данных.
- **Заявления об аттестации**: дополнительные ключи могут опционально иметь аттестацию. Это имеет решающее значение для понимания области применения и уровня безопасности дополнительных ключей. Аттестация может указывать на уровень защиты, обеспечиваемый аппаратно-привязанным ключом, или на политики для других типов дополнительных ключей.
- **Реализация для проверяющих сторон**: проверяющие стороны могут запрашивать эти дополнительные ключи как часть процесса аутентификации. Однако сложность работы с несколькими ключами и заявлениями об аттестации означает, что это расширение лучше всего подходит для организаций с особыми потребностями в безопасности, таких как банки или службы, работающие в соответствии со строгими нормативными требованиями.

Крайне важно отметить, что по состоянию на апрель 2024 года расширение **supplementalPubKeys** не было принято ни одним крупным браузером, а спецификация WebAuthn Level 3 все еще находится в стадии разработки и может быть изменена. Будет ли эта функция включена в финальную версию спецификации, а также ее потенциальная будущая реализация и принятие, остается неясным, поскольку в настоящее время она находится только в статусе черновика редактора (Editor’s Draft).

#### 3.4.3 Прекращение поддержки supplementalPubKeys в августе 2024 года

По состоянию на август 2024 года разработка расширения **supplementalPubKeys** была официально прекращена. Рабочая группа WebAuthn решила удалить эту функцию из-за недостаточной поддержки. Отказ от этого расширения также подчеркивает новое направление. В настоящее время **FIDO Alliance** работает над разработкой другого подхода для поддержки **проверяющих сторон (Relying Parties)** с высокими требованиями к безопасности. Ожидается, что это готовящееся решение устранит пробелы, оставленные отказом от **supplementalPubKeys**, и предложит новые методы усиления процессов аутентификации в сценариях, где жесткие стандарты безопасности критически важны.

Для получения более подробной информации об отказе от использования см. официальный [пул-реквест WebAuthn на GitHub](https://github.com/w3c/webauthn/pull/2109).

## 4. Как Corbado на практике справляется с различиями между аппаратно-привязанными и синхронизируемыми ключами доступа

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

### Видимость доверия к устройствам для разных типов ключей доступа

Панель доверия к устройствам (Device Trust dashboard) Corbado показывает, как аппаратно-привязанные и синхронизируемые ключи доступа по-разному работают в рабочей среде. Аппаратно-привязанные ключи доступа достигают более высокого процента успешности (99,1 %) с нулевыми требованиями к дополнительным проверкам (step-up), в то время как синхронизируемые ключи доступа с сигналами доверия к устройству достигают 98,4 % с небольшим процентом дополнительных проверок для новых устройств.

![Панель доверия к устройствам Corbado](https://www.corbado.com/website-assets/corbado_device_trust_dashboard_42ce934484.png)

Панель управления также отслеживает классификацию устройств — определяя, какие устройства принадлежат исключительно одному пользователю (92 % в типичных развертываниях для [банковской сферы](https://www.corbado.com/passkeys-for-banking)), какие используются совместно двумя пользователями (7 %), а какие являются совместно используемыми устройствами или киосками (0,8 %). Эта классификация напрямую влияет на решения о соответствии SCA.

### Управление на основе политик для различных сценариев использования ключей доступа

Вместо того чтобы относиться ко всем ключам доступа одинаково, политики доверия Corbado позволяют банкам применять разные правила на основе типа ключа доступа, статуса устройства и уровня доверия. Аппаратно-привязанные ключи доступа на известных устройствах получают беспрепятственную аутентификацию, в то время как синхронизируемые ключи доступа на новых устройствах вызывают дополнительную проверку (step-up verification) — именно тот детализированный подход, которого требует система SCA в рамках PSD2.

![Конфигурация политики доверия Corbado](https://www.corbado.com/website-assets/corbado_trust_policy_80ad56409f.png)

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

> **Позиция Corbado в отношении PSD2/SCA и ключей доступа:** Ключи доступа (как аппаратно-привязанные, так и синхронизируемые) могут соответствовать требованиям SCA. Каждое учреждение должно самостоятельно проводить оценку рисков SCA, но факты очевидны: ключи доступа по своей сути обеспечивают два фактора SCA — владение (закрытый ключ в аппаратном модуле безопасности или облачной связке ключей) + присущность (биометрия) или знание (PIN-код). Дискуссия о «владении» имеет множество нюансов, но разрешима — отрасль приходит к трем подходам: (1) **Ключи доступа как есть** (например, Revolut, Finom) — присущность + владение через устройство с закрытым ключом, (2) **Ключи доступа + привязка к cookie/сессии** (например, PayPal, Comdirect) — дополнительный сигнал владения для консервативной интерпретации, (3) **Криптографическая привязка (DBSC/DPoP)** — аппаратно-привязанное доказательство владения, самая надежная гарантия. Пока не существует единой «правильной» интерпретации. Требуется подход к SCA, ориентированный на результат — сосредоточение внимания на доказуемой устойчивости к фишингу, а не на жесткой категоризации факторов. Динамическое связывание остается отдельным требованием для [платежей](https://www.corbado.com/passkeys-for-payment) даже при использовании ключей доступа.

## Часто задаваемые вопросы

### Как аппаратно-привязанные ключи доступа повышают безопасность?

Аппаратно-привязанные ключи доступа — это учетные данные WebAuthn, строго привязанные к устройству, на котором они были созданы. В отличие от синхронизируемых ключей доступа, они остаются на одном устройстве, что делает их более безопасными для определенных сценариев использования:

- **Кража учетных данных невозможна**: закрытый ключ никогда не покидает устройство, поэтому злоумышленники не могут его перехватить.
- **Предотвращение несанкционированного доступа**: аутентификация происходит только с того устройства, где был создан ключ доступа.
- **Независимость от облака**: устраняются риски, связанные с утечками данных в облаке или захватом учетных записей.
- **Соответствие строгим требованиям безопасности**: отвечает жестким требованиям к аутентификации с привязкой к устройству для регулируемых отраслей, таких как [финансовые услуги](https://www.corbado.com/passkeys-for-banking) (AAL3).

Главный недостаток — ограниченная мобильность. Если устройство утеряно, ключ доступа не может быть восстановлен, если только пользователь не зарегистрирует новый на другом устройстве.

### Зачем были введены синхронизируемые ключи доступа и в чем их преимущества?

Синхронизируемые ключи доступа (ключи доступа для нескольких устройств) были созданы для решения проблем с удобством использования аппаратно-привязанных ключей, в частности, из-за отсутствия мобильности и потенциальной блокировки учетной записи при потере устройства. Основные преимущества:

- **Аутентификация на нескольких устройствах**: доступ к учетным записям с нескольких устройств без необходимости ручной регистрации нового ключа доступа для каждого из них.
- **Нет риска потери доступа**: учетные данные резервируются в облаке (например, iCloud Keychain, Google Password Manager), обеспечивая восстановление при потере устройства.
- **Улучшенный UX**: устраняет трения, избавляя от необходимости вручную переносить или заново создавать учетные данные.
- **Не требуется дополнительное оборудование**: в отличие от аппаратных ключей безопасности, синхронизируемые ключи доступа используют встроенные модули безопасности устройства.
- **Надежная безопасность с облачным удобством**: сквозное шифрование гарантирует, что закрытый ключ никогда не покидает устройство в незашифрованном виде.

## 5. Заключение

В первой части нашей серии из четырех статей мы проанализировали исторические и технические различия между аппаратно-привязанными и синхронизируемыми ключами доступа. Понимание этих различий поможет нам соответствующим образом применить требования PSD2 и SCA. Мы также взглянули в будущее, рассмотрев последние изменения в развивающемся стандарте WebAuthn Level 3.

Вот ссылки на другие части нашей серии:

- Часть 2 «Анализ требований PSD2 и SCA (SCA и ключи доступа II)»
- Часть 3 «Что требования SCA означают для ключей доступа (SCA и ключи доступа III)»
- Часть 4 «Последствия PSD3 / PSR для ключей доступа (SCA и ключи доступа IV)»