Passkey позволяет подтвердить действие тем же способом, которым пользователь разблокирует телефон или компьютер: биометрией, PIN-кодом устройства или аппаратным ключом. За удобным жестом работает WebAuthn – протокол с парой открытого и закрытого ключей. Сервис хранит public key, а секрет остаётся у authenticator или у провайдера синхронизации в защищённом виде.
В криптокошельке passkey может выполнять разные роли. В одном продукте он только открывает приложение, а транзакции подписывает отдельный приватный ключ. В другом он является on-chain signer программируемого аккаунта. В третьем passkey разрешает backend или защищённому enclave подписать операцию. Эти модели нельзя объединять фразой «кошелёк без seed-фразы».
Что такое passkey
Passkey – FIDO credential для аутентификации без пароля. При регистрации authenticator создаёт новую криптографическую пару для конкретного relying party. Public key и идентификатор credential передаются сервису, private key не передаётся сайту. При входе сервис отправляет случайный challenge, authenticator подписывает его после локальной проверки пользователя, а сервер проверяет подпись.
WebAuthn привязывает credential к relying party ID и origin. Поддельный сайт с другим доменом не должен получить корректную подпись для настоящего сервиса. Это делает passkeys устойчивее к обычному фишингу паролей и одноразовых кодов. Но протокол не анализирует смысл криптовалютной транзакции: пользователь способен безопасно войти в настоящий кошелёк и затем подтвердить опасный контрактный вызов.
Биометрические данные обычно проверяются локально операционной системой или authenticator. Сайт получает факт user verification и криптографическую подпись, а не изображение отпечатка или лица. PIN устройства также не является private key и не отправляется relying party.
Из чего состоит WebAuthn-подпись
При создании credential кошелёк или сервис задаёт relying party, challenge, параметры пользователя и поддерживаемые алгоритмы. Authenticator возвращает credential ID, public key и attestation data. Политика продукта решает, нужно ли проверять модель устройства по attestation или достаточно самого ключа.
При подтверждении authenticator формирует authenticator data и подписывает его вместе с хешем client data. В client data входят тип операции, challenge и origin. Счётчик, флаги присутствия пользователя и user verification помогают relying party применять собственную политику.
Большинство passkeys использует кривую P-256, также называемую secp256r1. Обычные Ethereum EOA исторически используют secp256k1. Поэтому WebAuthn-подпись нельзя просто подставить вместо стандартной ECDSA-подписи EOA. Нужен smart account, специальный verifier, поддержка P-256 на уровне сети или другой слой, который преобразует авторизацию в допустимую on-chain операцию.
Passkey для входа и passkey для активов
Первый вариант – аутентификация интерфейса. Passkey подтверждает, что пользователь может войти в аккаунт сервиса. Приватный ключ кошелька при этом хранится отдельно: на устройстве, в MPC-системе, hardware security module или защищённой инфраструктуре провайдера. Потеря passkey запускает процедуру восстановления аккаунта сервиса, а не обязательно on-chain смену владельца.
Второй вариант – непосредственный signer smart account. Public key passkey записывается в конфигурацию программируемого кошелька, а контракт проверяет WebAuthn/P-256 signature. Тогда действующий credential способен авторизовать UserOperation или контрактную транзакцию. Пример такой архитектуры – Safe, где passkey signer совместим с ERC-1271 и может использовать нативную P-256-проверку сети либо verifier contract.
Третий вариант – passkey как разрешение для удалённой подписи. Пользователь проходит WebAuthn, а сервисная инфраструктура проверяет credential и применяет собственный wallet key. Здесь passkey защищает доступ к signer, но on-chain виден ключ или аккаунт провайдера. Без документации и анализа контрактов нельзя утверждать, что private key активов физически совпадает с passkey.
Связь со smart accounts
ERC-4337 позволяет account contract самостоятельно определить допустимую подпись. Поле signature в UserOperation не обязано содержать обычную подпись EOA. Аккаунт может проверить passkey, multisig, guardian approval или сочетание факторов.
Для WebAuthn signer контракт получает public key coordinates, authenticator data, client data и компоненты P-256 signature. Он должен проверить challenge, origin или их закодированное представление, флаги и собственный контекст операции. Ошибка в verifier способна принять подпись от другого relying party или неправильно связать её с UserOperation.
Smart account добавляет recovery и замену signer, но также добавляет implementation, modules, bundler и иногда paymaster. Если аккаунт обновляемый, администратор может изменить правила проверки passkey. Поэтому удобство WebAuthn не отменяет проверку proxy admin и implementation.
Синхронизируемые и device-bound passkeys
Synced passkey доступен на нескольких устройствах через credential manager. Провайдер хранит зашифрованную копию и переносит её в рамках защищённой учётной записи. Пользователь получает удобное восстановление после замены телефона, но безопасность зависит от аккаунта синхронизации, его recovery и защиты новых устройств.
Device-bound passkey не покидает конкретный authenticator. Это может быть hardware security key или защищённый модуль устройства. Компрометация облачной учётной записи не копирует такой ключ, однако потеря единственного устройства уничтожает доступ к credential. Нужен второй signer или заранее настроенный recovery.
Название passkey в интерфейсе не всегда показывает тип хранения. Одни платформы синхронизируют credentials по умолчанию, другие создают привязанные к устройству ключи. Кошелёк должен объяснять, где находится credential, можно ли его перенести и что произойдёт после выхода из platform account.
Что происходит при смене телефона
Для synced passkey пользователь входит в ту же учётную запись credential provider и получает доступ на новом устройстве после её проверок. Это recovery платформы, а не блокчейна. Если злоумышленник захватит аккаунт и добавит доверенное устройство, он может получить возможность подтверждать действия, если продукт не требует дополнительного фактора.
Для device-bound passkey автоматического переноса нет. Кошелёк должен позволять заранее добавить второй credential, guardian, аппаратный signer или иной путь восстановления. Если единственный ключ является единственным on-chain owner и копии нет, разработчик не способен восстановить активы без предусмотренного контрактом механизма.
При cross-device authentication телефон может подтвердить вход на компьютере после проверки физической близости. Это не обязательно переносит passkey на компьютер. Пользователь должен различать временное подтверждение с другого устройства и создание нового credential.
Recovery: кто возвращает доступ
Recovery бывает платформенным и on-chain. Платформенное восстановление возвращает доступ к синхронизируемому passkey или аккаунту сервиса. Его правила задаёт Apple, Google, менеджер паролей или другой провайдер. On-chain recovery изменяет signer smart account через guardians, multisig, timelock или отдельный модуль.
Некоторые кошельки объединяют оба уровня. Пользователь восстанавливает аккаунт по email или social login, backend подтверждает личность и помогает назначить новый signer. Такой UX может быть удобным, но даёт сервису значительную роль. Нужно узнать, способен ли backend единолично восстановить кошелёк, требуется ли задержка и можно ли отменить подозрительную замену.
Фраза «не нужен seed» описывает интерфейс, а не отсутствие секретов. Секретный материал всё равно существует: passkey, device key, доли MPC или ключ сервисной инфраструктуры. В классическом кошельке пользователь отвечает за резервную копию seed-фразы, а в passkey-модели он отвечает за доступ к authenticator и правила recovery.
Преимущества passkeys
- Устойчивость к фишингу входа. Credential привязан к relying party и не раскрывает общий пароль.
- Нет повторно используемого секрета на сервере. Утечка базы public keys не даёт готовых credentials.
- Понятное подтверждение. Пользователь применяет привычную локальную биометрию или PIN.
- Быстрое создание кошелька. Не нужно сразу переписывать мнемоническую фразу.
- Гибкие signers. Smart account может сочетать passkey с аппаратным ключом, guardians и лимитами.
- Синхронизация. Synced credential упрощает переход между устройствами.
Основные риски
- Путаница ролей. Passkey может защищать только вход, а активами фактически управляет другой ключ.
- Зависимость от provider account. Компрометация облачного recovery способна открыть synced credential.
- Потеря device-bound ключа. Без второго signer доступ может исчезнуть навсегда.
- Ошибка WebAuthn verifier. Контракт или backend может неверно проверить challenge, origin или signature.
- Upgrade risk. Новая implementation smart account способна изменить правила авторизации.
- Централизованное recovery. Сервис или небольшой guardian set может заменить владельца.
- Фишинг транзакции. Защищённый вход не объясняет spender, сумму и calldata.
- Непереносимость. Экспорт credential между разными экосистемами может быть ограничен.
- Блокировка аккаунта. Потеря доступа к platform account или изменение политики провайдера усложняет вход.
- Cross-chain различия. Один passkey может владеть разными smart accounts и modules в разных сетях.
Почему биометрия не подписывает транзакцию сама
Отпечаток или лицо обычно только разблокирует использование ключа внутри authenticator. Криптографическую подпись создаёт закрытый ключ passkey. Это важное разделение: смена отпечатка на устройстве не обязана менять public key кошелька, а утечка биометрического шаблона не превращается напрямую в on-chain signature.
Операционная система решает, какая локальная проверка допустима. На одном устройстве это лицо, на другом PIN, на hardware key – физическое касание и собственный PIN. Кошелёк может требовать флаг user verification, но не всегда знает, каким именно методом пользователь разблокировал authenticator.
Passkey не заменяет проверку транзакции
WebAuthn подтверждает авторизацию, а не экономический смысл операции. Перед подписью пользователь всё равно должен видеть сеть, адрес назначения, токен, сумму, spender, срок и ожидаемые изменения. Если кошелёк показывает только «подтвердить», удобная биометрия ускоряет и безопасное, и опасное действие.
Для typed data полезен отдельный чек-лист проверки EIP-712. Для smart account нужно дополнительно понимать UserOperation, paymaster и modules. Passkey снижает риск кражи пароля, но не исправляет blind signing и вредоносную dApp.
Как оценить кошелёк с passkeys
- Определите роль. Passkey открывает приложение, непосредственно подписывает on-chain операцию или разрешает backend signing?
- Найдите владельца. Какой public key или контракт записан owner аккаунта?
- Уточните хранение. Credential synced или device-bound, у какого провайдера?
- Проверьте recovery. Кто может добавить новый signer, какой threshold и delay?
- Проверьте контракт. Верифицированы ли implementation и WebAuthn verifier?
- Проверьте upgrade. Кто контролирует proxy и модули?
- Добавьте резерв. Можно ли зарегистрировать второй passkey или аппаратный signer?
- Испытайте восстановление. Сделайте это до хранения значительной суммы, не удаляя рабочий credential.
- Проверьте экспорт. Можно ли выйти из продукта и сохранить контроль над активами?
- Разделите устройства. Для крупного баланса резервный signer лучше не хранить в той же учётной записи и на том же телефоне.
Практическая схема для разных сумм
Для небольшого повседневного кошелька synced passkey может дать разумный баланс удобства и защиты от фишинга входа. Включите сильную защиту platform account, проверьте список доверенных устройств и добавьте альтернативный recovery.
Для значимой суммы полезен smart account с несколькими независимыми signers. Основной passkey может оставаться на телефоне, второй – быть device-bound на аппаратном ключе, а recovery – проходить через guardians с задержкой. Конкретный threshold зависит от числа доступных участников и допустимого риска потери.
Для treasury passkey удобен как один из owners, но не как единственный путь. Multisig, отдельные устройства, лимиты, timelock и процедура замены сотрудников защищают лучше, чем один synced credential администратора.
Итог
Passkeys заменяют пароль криптографическим credential, привязанным к relying party. В криптокошельках они могут защищать вход, управлять smart account или разрешать удалённую подпись. Без понимания этой роли невозможно оценить self-custody и recovery.
Сильная схема сочетает phishing-resistant WebAuthn с прозрачным on-chain владельцем, независимым резервным signer и ограниченным recovery. Удобство passkey действительно убирает часть проблем seed-фраз, но переносит внимание на credential provider, код verifier, upgrade-полномочия и процедуру смены устройства.
