Passkeys и WebAuthn PRF для сквозного шифрования (2025)

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

• Варианты использования Passkey PRF: Каковы интересные сценарии применения расширения WebAuthn PRF?
• Поддержка расширения PRF: Какова реальная текущая поддержка расширения WebAuthn PRF в операционных системах и браузерах на сегодняшний день?

В этой статье анализируется расширение WebAuthn PRF, рассматриваются его технические спецификации, варианты использования, детали реализации, соображения безопасности и текущее состояние поддержки в браузерах и операционных системах. Мы сосредоточимся на изменениях в экосистеме 2025 года и разовьем основы, заложенные Мэтью Миллером и Леви Шуком в 2023 году, чьи ранние статьи предоставляют подробную техническую информацию, живые примеры и онлайн-тесты (включая шифрование).

Расширение WebAuthn PRF (PRF) формально определено в спецификации WebAuthn Level 3. Его основная цель — позволить доверяющей стороне (вашему веб-приложению) запрашивать вычисление псевдослучайной функции, связанной с конкретными учетными данными WebAuthn (Passkey), во время церемонии аутентификации (navigator.credentials.get()).

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

Многие аутентификаторы, особенно ключи безопасности FIDO2, реализуют базовую возможность, определенную в протоколе Client-to-Authenticator-Protocol (CTAP2), называемую расширением hmac-secret. Это расширение CTAP2 предоставляет доступ к аппаратной функции HMAC (Hash-based Message Authentication Code), которая служит псевдослучайной функцией. Расширение WebAuthn PRF действует как стандартизированный способ для веб-приложений получать доступ к этой возможности hmac-secret через API WebAuthn браузера.

Чтобы предотвратить потенциальные конфликты или проблемы безопасности, когда веб-сайт может обманом заставить аутентификатор генерировать HMAC, предназначенные для не-веб-целей (например, для входа в локальную ОС), спецификация WebAuthn предписывает важный шаг: входные данные, предоставленные веб-сайтом (первая и вторая соли), сначала хешируются с определенной контекстной строкой («WebAuthn PRF» и нулевой байт), прежде чем передаваться в базовую функцию hmac-secret. Это эффективно разделяет пространство входных данных PRF, гарантируя, что выводы, полученные из веба, отличаются от тех, которые потенциально используются в других контекстах.

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

1. Клиентское / сквозное шифрование (E2EE): Это основной мотив для расширения WebAuthn PRF. Браузерные приложения могут получать уникальный ключ шифрования для каждых учетных данных во время входа. Этот ключ затем можно использовать с WebCrypto API для шифрования пользовательских данных, хранящихся локально или на сервере. Данные остаются зашифрованными в состоянии покоя и могут быть расшифрованы только пользователем после успешной аутентификации с помощью конкретного Passkey, что повышает конфиденциальность и безопасность данных. Поставщики услуг могут хранить пользовательские данные, не имея доступа к открытому тексту. Это особенно полезно для приложений в мире без паролей, потому что без расширения PRF им пришлось бы дополнительно запрашивать секрет в виде пароля, что противоречит беспарольной архитектуре.

2. Беспарольная расшифровка хранилища: Сервисы, такие как менеджеры паролей (например, Bitwarden, 1Password) или приложения для защищенных заметок (например, Notesnook, Reflect), могут использовать PRF для замены традиционного мастер-пароля. Пользователь аутентифицируется с помощью своего Passkey, расширение PRF получает ключ для расшифровки хранилища, и хранилище разблокируется — мастер-пароль не требуется. Bitwarden объявил о поддержке этой функции. Более того, Dashlane недавно внедрил расширение WebAuthn PRF, чтобы усилить защиту от фишинга и повысить безопасность доступа к зашифрованным хранилищам. Пользователи аутентифицируются с помощью своих Passkey, что позволяет PRF безопасно получать ключи для расшифровки хранилища, полностью устраняя необходимость в мастер-пароле.

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

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

Хотя спецификация определена, фактическая поддержка в браузерах и на платформах является критическим фактором для разработчиков. Поддержка развивалась и до недавнего времени была в основном ограничена браузерами на базе Chromium. Отслеживание поддержки может быть сложной задачей, поскольку на CanIUse.com нет отдельной записи для самого расширения PRF (поиск по «webauthn» показывает общую поддержку API, но не конкретных расширений). Информацию часто приходится собирать из примечаний к выпускам браузеров, баг-трекеров и страниц статуса. Успешное использование расширения WebAuthn PRF требует скоординированных усилий на трех различных уровнях технологического стека. Поддержка расширения PRF должна присутствовать на каждом уровне, чтобы функция работала:

1. Аутентификатор: Это аппаратное (например, ключ безопасности) или платформенное (например, Windows Hello, Связка ключей iCloud и соответствующий аппаратный модуль, например, TPM или Secure Enclave) устройство, которое надежно хранит секретный ключ учетных данных и выполняет фактическое вычисление псевдослучайной функции (обычно с использованием возможности CTAP2 hmac-secret). Если у аутентификатора отсутствует эта фундаментальная криптографическая возможность, PRF работать не будет.

2. Операционная система (ОС): ОС выступает в роли моста между браузером и аутентификатором. Она предоставляет необходимые драйверы и системные API, чтобы браузер мог обнаруживать, общаться и запрашивать операции у аутентификаторов (особенно у платформенных аутентификаторов и тех, что подключены через USB/NFC/Bluetooth). ОС должна уметь распознавать и предоставлять браузеру возможность PRF (hmac-secret) аутентификатора. Если ОС не предоставляет этот путь, браузер не сможет получить доступ к функции.

3. Браузер: Являясь интерфейсом для веб-приложения, браузер должен реализовывать JavaScript API WebAuthn, в частности, распознавать расширение prf, преобразовывать веб-запрос в соответствующие команды для ОС/аутентификатора, выполнять критически важный шаг безопасности по хешированию входных данных с контекстной строкой, а также правильно анализировать и возвращать результаты приложению.

Сбой или отсутствие поддержки на любом из этих трех уровней — возможности аутентификатора, предоставления ОС или реализации в браузере — помешает работе расширения PRF.

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

Функционирующий рабочий процесс PRF требует взаимодействия каждого уровня в цепочке WebAuthn ↔ CTAP. Для ясности мы разделим обсуждение на (1) поведение браузера + операционной системы и (2) поведение аутентификатора.

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

Ниже мы рассмотрим поддержку по операционным системам.

Поддержка расширения WebAuthn PRF в Windows ограничена, поскольку встроенный платформенный аутентификатор (Windows Hello) в настоящее время не имеет необходимой возможности hmac-secret. Таким образом, функциональность PRF зависит от внешних ключей безопасности.

С выходом macOS 15 появилась поддержка PRF для платформенных аутентификаторов. И Safari, и Chrome поддерживают PRF через Связку ключей iCloud. Поддержка платформенного аутентификатора в Firefox все еще ожидается. Ключи безопасности работают только с Chrome.

Ситуация на iOS и iPadOS повторяет macOS, где PRF работает через Связку ключей iCloud. Однако есть существенные оговорки: ошибка в ранних версиях iOS 18 может привести к потере данных, а поддержка внешних ключей безопасности еще не реализована.

Android в настоящее время предлагает самую надежную и широкую поддержку расширения WebAuthn PRF. Passkeys, хранящиеся в Менеджере паролей Google, по умолчанию включают поддержку PRF, и она работает в большинстве основных браузеров, за исключением Firefox.

В таблице выше мы включили наиболее важные комбинации для поддержки основных поставщиков Passkey. Однако при использовании менеджеров паролей в качестве сторонних поставщиков Passkey их специфические возможности необходимо рассматривать отдельно. Например, 1Password поддерживает PRF в своей версии для Android, но не в версии для iOS. Также профиль Chrome в качестве аутентификатора не поддерживает PRF. Для получения более подробной информации об аутентификаторах см. ниже.

В то время как WebAuthn определяет, что доверяющая сторона может запросить, протокол Client-to-Authenticator Protocol (CTAP) определяет, как должен вести себя аутентификатор. На практике аутентификаторы делятся на четыре категории:

1. Нет поддержки PRF: Старые платформенные аутентификаторы (например, Windows Hello), устаревшие ключи безопасности без расширения hmac-secret и сторонние поставщики, которые еще не внедрили расширение PRF.

2. PRF только если флаг PRF был установлен при создании учетных данных: Некоторые ключи безопасности CTAP 2.0/2.1 предоставляют hmac-secret, но откажут в вычислениях PRF, если доверяющая сторона не запросила это при первоначальном создании учетных данных для инициализации секретов.

3. PRF доступен при аутентификации, даже если не был запрошен при создании: Аппаратные токены нового поколения, а также Связка ключей iCloud и Менеджер паролей Google предоставляют функциональность hmac-secret безусловно; учетные данные, созданные без этого флага, все равно работают с PRF во время navigator.credentials.get().

4. Полное соответствие CTAP 2.2 (PRF + первое значение PRF при создании): Платформенные аутентификаторы, которые синхронизируют Passkeys — такие как Связка ключей iCloud и Менеджер паролей Google — могут по запросу возвращать первый вывод PRF уже во время navigator.credentials.create(), упрощая процессы установления ключей.

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

Вы можете опробовать расширение WebAuthn PRF в действии, используя наше интерактивное демо-приложение WebAuthn PRF. В этом демо вы сможете:

• Зарегистрировать Passkey с PRF и убедиться, что ваш аутентификатор поддерживает это мощное расширение.
• Аутентифицироваться с помощью вашего Passkey и увидеть сгенерированное PRF криптографическое значение в действии.

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

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

Готовы проверить мощь PRF? Нажмите на изображение выше или перейдите по этой ссылке, чтобы начать практическое исследование.

Расширение WebAuthn PRF — не единственное расширение WebAuthn, связанное с хранением или получением данных. Как Passkey PRF выглядит на их фоне?

• PRF в сравнении с credBlob / largeBlob:

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

  • largeBlob: Позволяет хранить больше данных (~1 КБ) с обнаруживаемыми учетными данными, часто предназначен для вспомогательных данных, таких как сертификаты. Поддержка также ограничена (поддерживается Связкой ключей iCloud с iOS 17, но не GPM). Разработчики Chrome явно высказались за то, чтобы сосредоточиться на PRF, а не на largeBlob для большинства случаев использования, хотя разработка может произойти в будущем.

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

• PRF в сравнении с ключами, полученными из пароля (например, PBKDF2): Традиционно ключи для шифрования на стороне клиента получались из паролей пользователей. PRF предлагает значительные преимущества:

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

  • Устойчивость к фишингу: Получение ключа привязано к устойчивому к фишингу процессу аутентификации WebAuthn.

  • Беспарольность: Позволяет использовать такие сценарии, как расшифровка хранилища, вообще не требуя пароля.

• PRF в сравнении с другими данными WebAuthn: Попытка получить ключи из других частей ответа WebAuthn (например, из подписи, authenticatorData или открытого ключа) в корне небезопасна и неверна. Эти компоненты либо общедоступны, либо не являются секретными, либо предназначены для проверки, а не для получения ключей.

Для безопасного получения криптографического материала ключа, напрямую связанного с учетными данными WebAuthn или Passkey, расширение WebAuthn PRF является специально созданным и рекомендуемым стандартным подходом.

При интеграции расширения PRF в ваше приложение учитывайте эти практические рекомендации:

Следующие рекомендации помогут разработчикам эффективно ориентироваться в текущем состоянии поддержки расширения PRF и планировать будущие разработки:

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

• Избегайте критической зависимости от PRF: Не делайте PRF необходимым для критически важной функциональности. Текущая поддержка, особенно на таких платформах, как Safari на macOS и iOS, остается нестабильной и неполной.

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

• Ожидайте более широкой поддержки к 2026 году: Поддержка расширения PRF быстро развивается. К 2026 году можно ожидать стабильной доступности в основных браузерах, операционных системах и аутентификаторах, особенно у основных поставщиков Passkey.

• Следите за экосистемой Windows: Поддержка платформенного аутентификатора через Windows Hello в настоящее время отсутствует. Полная интеграция PRF в средах Windows сильно зависит от стратегии внедрения Microsoft, поэтому внимательно следите за этой экосистемой.

Следование этим рекомендациям гарантирует, что разработчики смогут плавно внедрить PRF, сохраняя совместимость и безопасность на этапе его внедрения.

Понимание того, как PRF согласуется с вашей общей стратегией Passkey, поможет вам максимизировать его преимущества без лишних сложностей:

• Гибкая интеграция: Не обязательно решать, использовать ли PRF в момент создания Passkey. Существующие Passkey могут быть позже без проблем интегрированы в сценарии использования PRF без дополнительных накладных расходов на управление учетными данными.

• Модернизация для поддержки PRF: Поскольку PRF работает на этапе аутентификации (navigator.credentials.get()), ранее созданные Passkey могут поддерживать рабочие процессы на основе PRF на более позднем этапе. Это позволяет вашему приложению постепенно повышать безопасность, не нарушая устоявшиеся методы аутентификации. Этот подход работает со Связкой ключей iCloud и Менеджером паролей Google (GPM), а также с новыми ключами безопасности. Для старых ключей безопасности hmac-secret может генерироваться только по запросу при создании учетных данных.

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

Рассмотрение PRF как части целостной стратегии Passkey обеспечивает более плавный переход к более безопасным и удобным для пользователя практикам аутентификации.

Для корпоративных поставщиков услуг, работающих с конфиденциальными пользовательскими данными, возможность использовать WebAuthn PRF вместе с Passkey открывает возможности для повышения безопасности и улучшения пользовательского опыта, особенно в сценариях, требующих шифрования персонально идентифицируемой информации (PII) на стороне клиента или защиты приложений, требующих сквозного шифрования. Хотя Corbado Connect в первую очередь предназначен для бесшовной корпоративной интеграции Passkey, он также может облегчить внедрение расширений Passkey, таких как SPC или PRF.

Вот как Corbado может помочь организациям, желающим интегрировать PRF:

• Облегчение использования PRF для зашифрованного хранения: В корпоративных средах иногда возникает требование безопасно хранить конфиденциальную информацию, возможно, даже непосредственно на стороне клиента, чтобы минимизировать раскрытие PII на стороне сервера. Corbado Connect можно настроить для запроса значений PRF во время процесса аутентификации с помощью Passkey (navigator.credentials.get()), что позволяет приложениям получать необходимые криптографические ключи.
• Гибкие шаблоны хранения: Данные, зашифрованные с помощью ключей, полученных через PRF, могут храниться различными способами в зависимости от требований безопасности и архитектуры:
  • На стороне клиента: Хранятся непосредственно в браузере с использованием таких механизмов, как localStorage или защищенные Cookies. Открытый текст данных существует только временно на клиенте во время расшифровки.
  • Бэкенд Corbado (E2EE): Хотя Corbado обычно избегает хранения PII клиентов, механизм PRF технически позволяет хранить зашифрованные на стороне клиента данные на серверах Corbado. У Corbado не будет ключей для расшифровки этих данных; расшифровка все равно будет происходить на стороне клиента после успешной аутентификации пользователя.
  • Бэкенд клиента: Зашифрованные данные также могут быть отправлены и сохранены на собственных бэкенд-системах предприятия, при этом все еще выигрывая от шифрования на стороне клиента.
• Безопасный процесс получения ключей: Компоненты Corbado Connect управляют взаимодействием с WebAuthn API. Когда запрашивается PRF:
  1. Аутентификатор генерирует специфичный для пользователя вывод PRF, привязанный к индивидуальному Passkey.
  2. Этот вывод безопасно возвращается в клиентское приложение.
  3. Затем приложение должно использовать функцию получения ключа (KDF) через WebCrypto API (например, HKDF) для получения надежного симметричного ключа шифрования из вывода PRF.
  4. Этот симметричный ключ используется с WebCrypto (например, AES-GCM) для шифрования или расшифровки целевой информации (например, PII).
• Бесшовная расшифровка при последующих входах: Когда пользователь снова аутентифицируется с помощью того же Passkey, Corbado Connect инициирует тот же запрос PRF. Это дает идентичный вывод PRF, позволяя приложению повторно получить тот же симметричный ключ и расшифровать ранее сохраненную информацию на стороне клиента.
• Аналитика внедрения PRF: Внедрение PRF требует знания, поддерживает ли его среда пользователя (ОС, браузер, аутентификатор). Corbado Connect собирает сигналы об устройстве и возможностях пользователя во время аутентификации. Эту информацию можно использовать для:
  • Определения готовности к PRF среди пользовательской базы перед полной активацией функций, зависящих от PRF.
  • Внедрения PRF по возможности, предоставляя его как улучшение для поддерживаемых пользователей, сохраняя при этом резервные механизмы (например, запрос на повторную верификацию или использование альтернативных методов) для тех, у кого нет поддержки.
• Оптимизация доступности PII: Используя PRF для шифрования проверенной PII (например, атрибутов личности, полученных в ходе процесса верификации) и хранения ее на стороне клиента, приложения могут сделать эти данные немедленно доступными после входа с помощью Passkey для последующих взаимодействий или транзакций, что значительно снижает трение по сравнению с повторной верификацией или потоками на основе приложений.
• Включение пользовательских систем E2EE: Хотя Corbado Connect предлагает компоненты пользовательского интерфейса для стандартных потоков, лежащие в его основе принципы могут позволить разработчикам более глубоко интегрировать функциональность PRF в чувствительные приложения. Это позволяет создавать системы со сквозным шифрованием, где фронтенд-приложение напрямую использует ключи, полученные через PRF, для сложных криптографических операций с существующими или новыми данными. На данный момент это все еще будет возможно только по возможности, и резервные механизмы должны будут реализовывать другой способ хранения этой информации.

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

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

Отвечая непосредственно на вопросы, поставленные в начале этой статьи:

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

• Текущее состояние поддержки PRF (июнь 2025 г.): Поддержка остается фрагментированной и постоянно развивается. В то время как Android имеет надежную поддержку в браузерах и аутентификаторах, на таких платформах, как macOS и особенно iOS, она нестабильна, особенно при использовании в качестве источника CDA из-за серьезной ошибки. Поддержка в Windows в основном ограничена внешними ключами безопасности, при этом встроенная поддержка платформы через Windows Hello заметно отсутствует.

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