Биометрия и осведомленность плательщика при динамическом связывании

Подход Corbado сочетает устойчивые к фишингу passkeys (SCA) с контролируемым банком экраном и серверным динамическим связыванием для соответствия статье 5 PSD2 RTS («что видишь, то и подписываешь»).

• Основная реализация (на сегодня): Мы отображаем сумму и получателя транзакции в пользовательском интерфейсе, контролируемом Bison-Bank, непосредственно перед и во время аутентификации с помощью passkey. Наш бэкенд генерирует одноразовый запрос (challenge), который привязан к каноническому снимку транзакции (сумма, получатель, txnId). Ответ принимается только в том случае, если он соответствует этому снимку; любое изменение делает его недействительным.

• Позиция регуляторов: Динамическое связывание остается обязательным для удаленных платежей даже при использовании passkeys (PSD2, ст. 97(2); RTS, ст. 5). RTS не требует, чтобы «код аутентификации» для динамического связывания вычислялся на устройстве; генерация/проверка на стороне сервера допустима, если обеспечиваются целостность отображения, специфичность и аннулирование при изменениях (см. также EBA Q&A 2020_5366 о том, где может вычисляться код).

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

• SCA: Два независимых элемента из разных категорий (знание/владение/неотъемлемое свойство), защищенные от раскрытия/копирования с помощью соответствующих мер (RTS, ст. 6–8). Требуется независимость (ст. 9), включая разделение при выполнении на многоцелевых устройствах (например, защита на уровне ОС, безопасное оборудование).
• Динамическое связывание (RTS, ст. 5):
  • (i) плательщик информируется о сумме и получателе во время аутентификации;
  • (ii) код аутентификации уникален для этой суммы/получателя;
  • (iii) любое изменение аннулирует код;
  • (iv) конфиденциальность/целостность суммы, получателя и кода защищены на всем пути. Это реализует регуляторный принцип «что видишь, то и подписываешь».
• Следствие: Одной только строгой аутентификации пользователя недостаточно для платежей. Одобрение должно быть привязано к конкретным данным транзакции с аудируемым подтверждением этой привязки и отображения информации плательщику (RTS, ст. 5(1)(a–d)).

Уточнение — фишинг и авторизация: Passkeys привязаны к источнику (origin), поэтому поддельные домены не могут получить действительные подписи. Однако PSD2 все равно требует динамического связывания для удаленных платежей, чтобы привязать авторизацию к точной сумме и получателю, аннулировать любые изменения и защитить целостность того, что отображается плательщику (RTS, ст. 5(1)(a–d)). Динамическое связывание обеспечивает целостность авторизации (включая атаки MITM/MITB/подмену TPP), а не только защищает от фишинга.

Заключение EBA 2019 года (EBA-Op-2019-06) подтверждает, что динамическое связывание привязывает аутентификацию к сумме и получателю, требует независимости факторов и признает криптографические ключи, привязанные к устройству, как элемент владения при наличии уникальной привязки к устройству. В нем также подчеркивается целостность информации, отображаемой плательщику во время аутентификации. EBA Opinion 2019

До PSD2 многие банки полагались на SMS OTP или печатные списки TAN, которые часто не показывали сумму или получателя на этапе подтверждения. Этот пробел облегчал обман клиентов с целью авторизации непреднамеренных переводов после кражи учетных данных. Динамическое связывание было введено, чтобы устранить этот пробел, гарантируя, что плательщик осведомлен о точной сумме и получателе в момент аутентификации, и делая код аутентификации специфичным для этих данных, чтобы любое изменение делало его недействительным (RTS, ст. 5(1)(a–d)). Если SMS является частью процесса, эмитенты также должны обеспечивать конфиденциальность, подлинность и целостность суммы/получателя и кода на всех этапах аутентификации (Q&A 2018_4414; RTS, ст. 5(2)). Сегодняшние подтверждения в приложениях (например, «Вы хотите авторизовать перевод 100 долларов США Джону Смиту через Face ID?») реализуют этот принцип «что видишь, то и подписываешь» в удобной для клиента форме.

Сегодня на мобильных устройствах доминируют две модели. Во-первых, push-уведомление может перенаправить клиента в приложение для просмотра деталей транзакции и ее подтверждения. Регуляторы уточнили, что push-уведомление может служить доказательством элемента владения, если приняты меры контроля по статье 7 для предотвращения несанкционированного использования и копирования, а весь процесс соответствует RTS; тем не менее, риски социальной инженерии остаются и должны учитываться в UX (Q&A 2019_4984; RTS, ст. 7).

Во-вторых, подтверждения с использованием встроенной биометрии устройства (с PIN-кодом в качестве запасного варианта) выполняют проверку пользователя локально, чтобы разблокировать операцию с закрытым ключом. Закрытый ключ хранится в безопасной аппаратной среде (Secure Enclave/TEE/TPM) и используется для подписи запроса (challenge). Это четко соответствует SCA: неотъемлемое свойство (биометрия) плюс владение, подтвержденное привязкой к устройству и криптографическим ключом, привязанным к устройству (EBA-Op-2019-06, параграфы 25, 35–37). Для удаленных платежей код должен быть динамически связан с суммой и получателем, и эти детали должны отображаться плательщику перед проверкой пользователя (RTS, ст. 5). Если оба фактора находятся на одном устройстве, необходимо реализовать раздельные безопасные среды выполнения и проверки целостности, чтобы компрометация одного не приводила к компрометации другого (RTS, ст. 9(2)–(3)).

Под капотом локальная биометрия не «аутентифицирует» пользователя напрямую в банке. Вместо этого биометрические данные (или запасной PIN-код) выполняют проверку пользователя на устройстве и открывают доступ к неэкспортируемому закрытому ключу, хранящемуся в аппаратном модуле безопасности. Когда плательщик дает согласие, устройство использует этот закрытый ключ для создания цифровой подписи под предоставленным банком запросом (challenge). Если банк выводит или связывает этот запрос с каноническим снимком транзакции (сумма, получатель, идентификаторы), то полученная подпись функционирует как код аутентификации, специфичный для этих данных. Любое изменение сделает код недействительным, потому что сохраненный снимок больше не будет совпадать, или, в усовершенствованных схемах, потому что изменится способ формирования запроса. Часть, касающаяся осведомленности плательщика, остается требованием к UX: необходимо показывать сумму и получателя в контролируемом банком представлении непосредственно перед проверкой пользователя. Вместе это удовлетворяет требованиям статьи 5 RTS по осведомленности, специфичности/уникальности и аннулированию при изменении, в то время как меры контроля по статье 7 и привязка к устройству подтверждают элемент владения.

• Владение (привязанные к устройству и синхронизируемые ключи): Закрытые ключи passkey хранятся в безопасном оборудовании (TEE/Secure Enclave/TPM). Passkeys, привязанные к устройству, не экспортируются, что соответствует ожиданиям EBA по уникальной привязке к устройству (EBA-Op-2019-06, параграфы 25, 35–37). Синхронизируемые passkeys также могут подтверждать владение при каждой аутентификации, при условии, что привязка к устройству и меры по борьбе с копированием эффективны; регуляторы подчеркивают необходимость надежной связи между элементом и устройством (EBA-Op-2019-06; RTS, ст. 7).
• Неотъемлемое свойство/знание (проверка пользователя): Проверка пользователя с помощью биометрии (неотъемлемое свойство) или PIN-кода устройства (знание) активирует ключ локально. В сочетании с владением это настоящая двухфакторная аутентификация (2FA) с независимостью факторов. Взлом одного не компрометирует другой.

Суть динамического связывания — привязка аутентификации к транзакции. Вопрос для банка: если мы позволяем пользователю подтвердить платеж с помощью passkey (а не, скажем, OTP или устройства для подписи), можем ли мы гарантировать, что это подтверждение специфично для предполагаемой суммы и получателя и не может быть повторно использовано или изменено?

Есть 2 варианта реализации динамического связывания с passkeys:

• Серверное связывание (стандартное): Сгенерировать одноразовый запрос WebAuthn (challenge), который бэкенд связывает с точной суммой и получателем. Пользователь видит «€X для Y» в контролируемом банком представлении и подтверждает с помощью passkey. Ответ принимается только для этой транзакции. Любое изменение делает его недействительным.
• Криптографическое включение (улучшенное): Встроить хэш суммы/получателя в запрос, чтобы подпись подтверждала данные транзакции. Это не требуется RTS, но добавляет уверенности, что даже подмена на бэкенде не пройдет проверку.

Примечание о соответствии требованиям: RTS не требует, чтобы «код аутентификации» для динамического связывания вычислялся на устройстве плательщика. Поставщик платежных услуг (PSP) может генерировать и проверять его на сервере, если сумма/получатель защищены и любое изменение аннулирует код (см. EBA Q&A 2020_5366 о месте/времени вычисления кода). Это и есть наш стандартный подход с серверным динамическим связыванием.

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

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

Меры контроля целостности отображения, которые мы применяем:

• Контролируемое банком представление отображает сумму + получателя: мы блокируем вызов passkey, если представление скрыто или не в фокусе.
• Обнаружение наложений/подделки в приложении/вебе: никаких запросов passkey из скрытых iframes.
• Проверка целостности/аттестации устройства: отклонение или повышение уровня безопасности при сигналах о root-доступе/джейлбрейке/компрометации.
• Атомарное подтверждение на основе хранящегося на сервере снимка суммы/получателя: при любом изменении параметров требуется новый запрос.

О криптографическом включении: Расширения WebAuthn для «отображения транзакций» (SPC) сегодня не имеют широкой поддержки. Наша универсальная основа — серверное связывание, усиленное получением запроса из снимка транзакции (например, H(сумма || получатель || txnId || nonce)), чтобы подпись подтверждала эти значения.

Обе модели используют криптографию с открытым ключом с неэкспортируемыми ключами устройства и обе полагаются на локальную проверку пользователя для разблокировки операции подписи. В обоих случаях банк обеспечивает осведомленность плательщика, показывая сумму и получателя в контролируемом банком представлении непосредственно перед проверкой пользователя, и обеспечивает специфичность, привязывая код аутентификации к этим данным — аннулируя его при любом изменении (RTS, ст. 5(1)(a–d)). RTS технологически нейтрален и не требует, чтобы сумма/получатель отображались внутри модального окна биометрии ОС; он требует отображения плательщику и привязки кода (RTS, ст. 5). Когда оба элемента SCA выполняются на одном устройстве, требования статьи 9 о целостности и разделении применяются в равной степени (RTS, ст. 9(2)–(3)). Наконец, место вычисления для динамического связывания может быть гибким: оно может выполняться на стороне сервера, если сохраняется целостность и любое изменение аннулирует код (Q&A 2020_5366). Это те же условия, при которых регуляторы уже принимают локальную биометрию с PKI — следовательно, passkeys, реализованные с теми же мерами контроля осведомленности и привязки, должны приниматься на эквивалентной основе.

Итак, соответствуют ли обычные passkeys согласно стандарту WebAuthn цели динамического связывания? Частично:

• Атаки MITM/сетевые атаки: Да. Привязка к источнику и подписи для каждого запроса предотвращают подделку и повторное использование.
• Целостность транзакции: Да. Ассоциация на сервере или хэширование запроса гарантируют, что проверку пройдет только исходная сумма/получатель.
• Согласие плательщика: Сложнее. В passkeys отсутствует отображение на уровне аутентификатора. Обман в интерфейсе на скомпрометированных устройствах может быть возможен. Нужно создать что-то дополнительное, чтобы гарантировать согласие плательщика.

Почему динамическое связывание все еще необходимо с passkeys

• Юридически: Статья 97(2) PSD2 и статья 5 RTS предписывают динамическое связывание для всех удаленных инициирований платежей. Исключений для методов, устойчивых к фишингу, нет.
• Безопасность: Passkeys устраняют междоменный фишинг, но сами по себе не подтверждают, что было показано плательщику. Динамическое связывание + меры контроля целостности отображения гарантируют, что банк исполнит транзакцию на конкретную сумму/получателя, которые видел пользователь, и что любое изменение аннулирует одобрение.

В итоге, passkeys могут удовлетворять требованиям динамического связывания, если они строго привязаны к данным транзакции и используются вместе с надежными механизмами отображения. Оставшаяся проблема — доказать, что именно видел пользователь.

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

// TODO PROVIDE MOCKUPS FROM KARUNA AND DESCRIBE THEM

Процесс:

• Контролируемый банком экран показывает плательщику точную сумму и получателя. Запрос на использование passkey не появляется, пока этот экран не будет виден.
• Аутентификация: клиент вызывает WebAuthn с одноразовым, привязанным запросом для канонизированной транзакции. Аутентификатор выполняет проверку пользователя (биометрия или PIN-код устройства) и подписывает запрос и источник.
• Проверка на сервере: бэкенд проверяет хэш RP ID и источник, сопоставляет запрос с сохраненной транзакцией, проверяет флаги UV, обеспечивает одноразовое использование и срок действия, а также сравнивает сохраненный снимок суммы/получателя.
• Подтверждение и аудит: только после этого транзакция атомарно подтверждается. Любое несоответствие/изменение отклоняется и требует новой аутентификации. Сохраняется неизменяемая аудиторская запись (ID учетных данных, authenticatorData, clientDataJSON, подпись, запрос и канонизированная сумма/получатель), опционально с хэш-цепочкой для доказательства отсутствия подделки.
• Проверка целостности устройства: Оценка сигналов целостности и аттестации устройства: отклонение или повышение уровня безопасности, если устройство имеет root-доступ/джейлбрейк/скомпрометировано.
• Канонизация получателя: Отображение понятного названия (например, «ACME GmbH»), но привязка и проверка по каноническому идентификатору получателя (например, IBAN/BIC или другая уникальная схема).

Технические детали:

• Бэкенд: создать объект транзакции с канонизированными данными (например, нормализованная валюта/десятичные знаки; канонизированный IBAN/получатель). Сгенерировать кратковременный запрос, подтверждающий эти значения (например, H(сумма||получатель||txnId||nonce)); сохранить в ожидании; предоставлять клиенту только непрозрачные ID.
• Клиент/аутентификатор: отобразить детали плательщика в контролируемом банком представлении; вызвать WebAuthn (RP ID = домен Bison) только когда он виден; потребовать проверку пользователя; аутентификатор подписывает запрос + источник согласно WebAuthn.
• Проверка/финализация: проверить подпись, хэш RP ID, источник/тип, флаги UV; защита от повторного воспроизведения/истечения срока; сравнить неизменяемый снимок суммы/получателя; атомарно подтвердить; сохранить аудиторскую запись.
• Получение запроса из снимка:: challenge = H(сумма ‖ каноническийПолучатель ‖ txnId ‖ nonce)

Политики UX:

• Четкий акцент на сумме/получателе; доступные элементы управления подтверждением/отменой; короткие тайм-ауты; корректные повторные попытки всегда с новым запросом; немедленные квитанции (например, «Вы подтвердили перевод €X для Y»). Блокировать запрос passkey, если экран скрыт, и предупреждать, если параметры меняются до подписи.
• Обнаруживать наложения/скрытый контент: никогда не показывать запрос passkey, если представление транзакции не видно. Отклонять, если параметры меняются в процессе, и перезапускать с новым запросом.

Примечание о соответствии требованиям: Эта комплексная архитектура соответствует статье 5 RTS: осведомленность плательщика (контролируемый банком экран), специфичность и уникальность (одноразовый код, привязанный к сумме/получателю), аннулирование при изменении (строгие серверные проверки) и конфиденциальность/целостность суммы/получателя и кода на всех этапах (RTS, ст. 5(1)(a–d), 5(2); см. также Q&A 2018_4414 по целостности SMS). Независимость факторов (ст. 7–9) сохраняется благодаря привязке к устройству и локальной проверке пользователя на многоцелевых устройствах с соответствующей защитой (RTS, ст. 9(2)–(3)).

Примечание:* для веб-процессов Corbado опционально будет использовать [Secure Payment Confirmation](https://www.w3.org/TR/payment-request-secure-payment-confirmation/), когда Apple обеспечит широкую поддержку, добавляя доверенное отображение через браузер, которое криптографически подтверждает сумму и получателя.

Проблема: Фишинговые атаки Решение: Passkeys по своей природе устойчивы к фишингу: они привязаны к легитимному источнику и не используют общих секретов, поэтому учетные данные нельзя похитить на поддельном сайте, в отличие от OTP. Злоумышленник, проксирующий трафик на похожий домен, не сможет получить действительную подпись для домена банка. Динамическое связывание в этом векторе менее значимо, но остается обязательным, чтобы гарантировать, что любое подтверждение уникально для предполагаемой суммы и получателя. Дополнительные меры (обучение по фишингу, четкое разделение между входом в систему и подтверждением платежей, оценка аномалий/рисков для необычных платежных контекстов) еще больше снижают риски.

Проблема: Социальная инженерия / Мошенничество с авторизованными push-платежами (APP) Решение: Ни один аутентификатор не может полностью помешать пользователю авторизовать платеж под ложным предлогом (например, мошенничество с «безопасным счетом»). Динамическое связывание гарантирует, что пользователь явно видит получателя и сумму, и предоставляет веские доказательства согласия, но оно не может переубедить введенного в заблуждение плательщика. Компенсирующие меры включают контекстные предупреждения (новый получатель, первый крупный перевод), периоды ожидания или отложенное исполнение для высокорисковых получателей, более строгую проверку получателя и дополнительные проверки (step-up) при сигналах риска. Уведомления после платежа и быстрые каналы для оспаривания помогают обнаруживать и сдерживать ущерб. Мы добавляем контекстные предупреждения в реальном времени (например, новый получатель, первый крупный перевод), периоды ожидания для высокорисковых получателей, более строгую проверку получателя и уведомления после платежа («Вы подтвердили перевод €X для Y»), чтобы ускорить обнаружение и реагирование.

Проблема: Вредоносное ПО или компрометация устройства Решение: Закрытые ключи не экспортируются и требуют локальной проверки пользователя для каждой подписи, поэтому вредоносное ПО не может просто извлечь учетные данные. Реальный риск — обман в интерфейсе на полностью скомпрометированной ОС. Снизить его можно с помощью безопасного/проверенного UI (например, защищенные подтверждения), проверок целостности устройства/аттестации и блокировки устройств с высоким риском, а также доверенных подтверждений, таких как SPC или расширение для подтверждения, когда оно будет доступно. Если появляются признаки компрометации (обнаружение наложений, root/джейлбрейк), использовать внеполосную повторную верификацию или отказать в выполнении. Ни один потребительский метод не идеален на полностью захваченном устройстве, но эти меры значительно сужают окно возможностей.

Проблема: Атака «человек в браузере» / перехват сессии Решение: Вредоносные расширения или внедренные скрипты могут инициировать действия на легитимном источнике. Passkeys, привязанные к источнику, останавливают межсайтовый фишинг. Динамическое связывание гарантирует, что скрытые изменения суммы/получателя не пройдут. Мы усиливаем канал с помощью CSP/мер защиты от подделки и требуем свежий, одноразовый запрос для каждого подтверждения.

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

Проблема: Украденные устройства / кража учетных данных Решение: Простого владения устройством недостаточно: для каждой подписи требуется проверка пользователя (биометрия/PIN) с ограничениями на количество попыток и блокировкой на уровне ОС. Каждый платеж требует свежего, специфичного для транзакции запроса; общие токены сессии не могут авторизовать произвольные платежи. Дополнения, такие как удаленная блокировка устройства, повышение уровня безопасности при использовании нового устройства, проверки гео-скорости и уведомления («Вы авторизовали €X для Y»), еще больше ограничивают злоупотребления.

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

Вопрос 1: Как мы можем доказать, что пользователь действительно видел и согласился с суммой и получателем при использовании passkey? Ответ: Это, по сути, вопрос неотказуемости. В рамках PSD2 динамическое связывание было предназначено для того, чтобы пользователь знал, что он подтверждает. С passkey доказательством, которое мы сохраняем, является криптографическая подпись (код аутентификации) и связанные с ней данные (к какой сумме/получателю она была привязана на нашем сервере). Политикой предусмотрено, что мы отображаем детали транзакции пользователю в приложении или на веб-странице перед аутентификацией. Мы логируем этот экран/представление и последующую успешную аутентификацию с помощью passkey для этой конкретной транзакции. В случае спора мы можем показать, что устройство пользователя создало действительную подпись для запроса, который был связан, например, с «€100 для ACME Corp.», и что наша система не продолжила бы работу, если бы какие-либо детали отличались. Наше соответствие требованиям зависит от безопасного логирования: мы обеспечиваем защиту наших систем от подделки при связывании ответа passkey с данными транзакции.

Вопрос 2: Что, если устройство или ОС скомпрометированы? Может ли вредоносное ПО манипулировать транзакцией или процессом passkey? Ответ: Компрометация устройства — критическая угроза в любом сценарии цифрового банкинга. Если операционная система вредоносна, она может попытаться ввести пользователя в заблуждение или перехватить процессы. Однако даже в этом худшем случае passkeys сохраняют некоторые ключевые защитные механизмы. Закрытый ключ не может быть извлечен вредоносным ПО. Вредоносное ПО также не может выдать себя за пользователя перед банком, потому что оно не может создать подпись passkey без биометрии/PIN-кода пользователя. Максимум, что оно может сделать, — это подтолкнуть пользователя к аутентификации чего-либо под ложным предлогом. Динамическое связывание здесь помогает, требуя проверок целостности: вредоносное ПО не может незаметно изменить детали транзакции после факта — если оно это сделает, подпись не пройдет проверку. Самое слабое место — это отображение/UI: сложный троян может изменить то, что видит пользователь (например, показать «ACME Corp», в то время как транзакция на самом деле идет другому получателю). Это нетривиально, особенно если банковское приложение использует безопасные фреймворки UI, но это возможно. Тем не менее, если мы обнаружим признаки компрометации устройства (необычное поведение, известные сигнатуры вредоносного ПО и т. д.), мы перейдем к внеполосной верификации или отклоним транзакцию. В итоге: ни одно решение не является 100% надежным, если устройство пользователя полностью контролируется злоумышленником. Passkeys + динамическое связывание значительно сокращают поверхность атаки (злоумышленник не может просто проксировать учетные данные или изменять сетевые данные; ему придется обманывать пользователя в реальном времени). Если ОС скомпрометирована, динамическое связывание по крайней мере гарантирует, что любое несоответствие между тем, что должно быть, и тем, что подтверждено, будет обнаружено нашим бэкендом.

Вопрос 3: Если для разблокировки passkey используется биометрия, считается ли это одним фактором или двумя? Соответствуем ли мы правилу двух факторов? Ответ: Одна только биометрия не достаточна для SCA — это всего лишь один фактор неотъемлемого свойства. Однако в реализации passkey биометрия не одна: владение устройством — это второй фактор. Биометрия пользователя разблокирует закрытый ключ, хранящийся на устройстве. Владение и неотъемлемое свойство — это две разные категории. Это аналогично тому, как многие банковские приложения уже удовлетворяют SCA: у вас есть телефон (владение), и вы используете отпечаток пальца или лицо для разблокировки приложения (неотъемлемое свойство). EBA явно признала комбинации привязки к устройству и биометрии как соответствующую SCA. Сценарий с passkey — это именно такая комбинация. Если пользователь выбирает использование PIN-кода вместо биометрии для разблокировки passkey, то это владение + знание, что также соответствует требованиям. Мы требуем проверку пользователя для всех операций с passkey (что означает, что пользователь должен каждый раз предоставлять биометрию/PIN), поэтому нет ситуации, когда достаточно просто иметь устройство. Таким образом, каждая авторизация платежа через passkey является двухфакторным событием согласно определениям PSD2.

Вопрос 4: Может ли злоумышленник повторно использовать аутентификацию passkey или как-то обойти динамическое связывание, манипулируя данными при передаче? Ответ: Нет. Именно здесь passkeys и динамическое связывание работают вместе очень эффективно. Каждая аутентификация WebAuthn создает уникальную подпись, которая привязана к запросу (который мы генерируем для каждой транзакции) и ограничена нашим доменом. Злоумышленник не может повторно использовать эту подпись для другой транзакции. Сама подпись включает nonce запроса и действительна только для того, для чего она была изначально выпущена. Если злоумышленник перехватит сетевое сообщение, он не сможет изменить сумму или получателя, не сделав подпись недействительной (поскольку запрос или контекст транзакции больше не будут совпадать). Это и есть эффективная защита от MITM, которую мы обсуждали. Кроме того, подписи passkey включают данные об источнике — они не пройдут проверку, если не будут отправлены на наш точный веб-сайт/источник приложения, поэтому фишинг или перенаправление не сработают. Короче говоря, любая попытка манипуляции делает код аутентификации недействительным, согласно правилам динамического связывания. Это на самом деле безопаснее, чем некоторые текущие потоки на основе OTP, где пользователи иногда подтверждают общий код, и существует риск, что запрос был подделан. С passkeys мы криптографически привязываем аутентификацию пользователя к конкретной сессии/транзакции.

Вопрос 5: Есть ли какие-либо известные регуляторные мнения о WebAuthn/passkeys для SCA? Уверены ли мы, что регуляторы примут passkeys как соответствующие требованиям? Ответ: На данный момент EBA не публиковала явных мнений о WebAuthn или термине «passkeys» в своих Q&A или руководствах. Однако, исходя из принципов, которые они изложили, passkeys явно вписываются в допустимые методы. Мнение EBA от 2019 года, по сути, предвосхитило подходы, подобные FIDO2: для владения они явно упоминают «обмен открытыми/закрытыми ключами» с надлежащей привязкой к устройству как доказательство владения. WebAuthn passkey — это именно то: пара открытого/закрытого ключей, где закрытая часть надежно привязана к устройству. Они также одобрили «подпись, сгенерированную устройством» как действительное доказательство владения. Так что, хотя они и не использовали термин passkey, этот метод покрывается их примерами. Мы также заметили, что крупные игроки в сфере платежей в Европе продвигаются с внедрением passkeys (например, PayPal), что указывает на определенный уровень уверенности в том, что это соответствует требованиям PSD2. Этот пример демонстрирует, что passkeys принимаются как часть соответствующих SCA потоков, при условии, что динамическое связывание и общие требования соблюдены.

Вопрос 6: Нужно ли нам все еще динамическое связывание, если passkeys устойчивы к фишингу? Ответ: Да. Passkeys устраняют междоменный фишинг, но PSD2 все еще предписывает динамическое связывание для удаленного инициирования платежей. Динамическое связывание привязывает конкретную сумму и получателя к результату SCA и аннулирует любые изменения, обеспечивая целостность авторизации не только от фишинга (например, подмена MITM/MITB/TPP).

Решение Corbado соответствует требованиям динамического связывания и PSD2. Отображение информации плательщику перед аутентификацией, одноразовый запрос, привязанный к сумме и получателю, строгая серверная проверка и неизменяемый аудит в совокупности удовлетворяют требованиям статьи 5 RTS по осведомленности плательщика, уникальности/специфичности, аннулированию при изменении и целостности/конфиденциальности. Независимость факторов сохраняется благодаря владению, привязанному к устройству, и проверке пользователя (биометрия или PIN), что соответствует руководствам EBA.

По сравнению с сегодняшними методами OTP/SMS, Corbado обеспечивает значительно лучшую безопасность и пользовательский опыт: устойчивость к фишингу и ретрансляции, предотвращение незаметной подделки параметров, более надежные неопровержимые доказательства и снижение трения благодаря проверке пользователя на устройстве. Остаточные риски (например, социальная инженерия, скомпрометированные устройства) смягчаются конкретными мерами контроля и являются менее значительными, чем при использовании устаревших методов. Для веба Corbado может использовать SPC, когда поддержка платформ (особенно Apple) станет широкой, добавляя криптографическое доказательство отображения без изменения основной позиции по соответствию требованиям.

Короче говоря, авторизация транзакций на основе passkey от Corbado соответствует букве и духу динамического связывания PSD2 и повышает устойчивость к мошенничеству и аудируемость по сравнению с устаревшими подходами, сохраняя при этом четкий путь к будущим улучшениям (SPC) по мере развития экосистемы.

На практике passkeys удовлетворяют требованиям динамического связывания, когда мы делаем три вещи: отображаем сумму и получателя плательщику перед проверкой пользователя; генерируем код аутентификации, специфичный для этих точных данных; и аннулируем код при любом изменении (RTS, ст. 5(1)(a–d)). Это отражает принципы, которые регуляторы уже принимают для локальной биометрии, с дополнительным удобством, заключающимся в том, что passkeys являются нативными для ОС и работают как в вебе, так и в приложениях без дополнительного приложения. В сочетании с привязкой к источнику они не показывают поддельные запросы — пользователю отображаются только легитимные запросы с оригинального сайта или приложения.