Все говорят о Абстракции счета (AA) и ее потенциале изменить пользовательский опыт в пространстве блокчейна. Однако основное недопонимание об АА заключается в том, что она выходит за рамки простого абстрагирования газовых сборов или возможности пакетных транзакций. Как? Через программные системы управления ключами.

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

Преодолевая 12 слов

Наша отрасль обожает модные слова, и «без семян» - одно из последних, которое привлекает внимание. В то время как мы все согласны с тем, что ожидать от пользователей надежного хранения их приватных ключей является непрактичным и привело к потере миллионов долларов, остается вопрос: если мы не показываем пользователям фразы-семена, где мы храним ключи?

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

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

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

1. Полностью программируемые счета: абстрагирование счета

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

С AA средства хранятся в смарт-контрактах, а владение учетной записью определяется этими смарт-контрактами. Учетные записи, совместимые с EIP-4337, имеют две части в своих транзакциях.

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

Обе части полностью программируемы; например, вы можете определить два ключа (i, ii), и первый ключ (i) может выполнить немедленные транзакции, в то время как второй ключ (ii) может выполнить транзакции только после блокировки по времени. Это означает, что мы можем определить мощность ключей, добавить блокировку по времени или включить другие условия для выполнения транзакции.

Итак, когда речь идет о традиционных учетных записях (EOA), аутентификация равна авторизации. С AA авторизация программабельна, поэтому разработчики могут определить схему контроля доступа на основе ролей и обеспечить принцип наименьших привилегий.

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

Плюсы и минусы различных систем управления ключами

Я быстро расскажу о Passkeys (Consumer Secure Enclaves), MPC Based Solutions, Cloud-Based TEE solutions, Custodial Solutions, Traditional 12 words и Session Keys. После этого я объясню лучшие комбинации.

1. Традиционные 12 слов - (secp256k1) -

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

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

Однако есть некоторые недостатки:

1. Обучение пользователей безопасному хранению их ключей в случае потери устройств представляет собой сложную задачу.
2. Троян или вредоносное ПО могут украсть приватный ключ с устройств пользователей, поскольку он сохраняется в общем хранилище.

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

2. Парольные ключи (защищенные области потребителей)

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

Разработчики создали специальный микропроцессор, называемый Secure Enclave, чтобы управлять этими чувствительными операциями отдельно. Secure Enclave работает подобно аппаратному кошельку: он функционирует независимо, безопасно обрабатывает чувствительные данные, и даже владелец устройства не может получить к ним доступ. К счастью, Secure Enclave поддерживает криптографические операции, такие как создание приватных ключей и подписывание сообщений с их помощью. К сожалению, Secure Enclave не поддерживает кривую, которую поддерживает Ethereum (secp256k1), вместо этого он поддерживает кривую p256. Чтобы включить нативную проверку P256, мы (@getclaveКоманда @getclave предложилаRIP-7212и почти все крупные роллапы теперь поддерживают это.

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

• Проверка P256 без RIP-7212 дорогая и повышает риск ошибки.
• Поскольку ключ не может быть извлечен, восстановление здесь отсутствует функция (парольные ключи обеспечивают ограниченную восстановимость, но этого недостаточно)
• Если веб-домен ключа доступа или приложения Secure Enclave (SE) перестает работать, пользователи не могут получить доступ к закрытому ключу, потому что Secure Enclave разработан для изоляции и независимости. Без соответствующего приложения или веб-домена нет способа извлечь или взаимодействовать с закрытым ключом, что оставляет пользователей неспособными выполнять необходимые криптографические операции. - Я объясню, как решить эту проблему.

3. Решения по управлению ключами на основе SSS

Решения SSS (Shamir's Secret Sharing) создают способ устранения единой точки отказа, присущей традиционным системам управления ключами. Они фактически разделяют ключи на разные части и устанавливают порог для доступа к ключу. Распределением этих частей SSS гарантирует, что ни одно отдельное лицо не обладает всем ключом, тем самым повышая безопасность.

Давайте рассмотрим, где они хранят ключи и как они достигают кворума для доступа к закрытому ключу. Большинство существующих протоколов используют три ключевых доли: одна доля хранится на устройстве пользователя, одна хранится на их сервере (или в сети MPC), и одна резервируется в качестве резервной копии. Некоторые приложения, такие как Google Drive, используют облачные решения для хранения этих ключевых долей.

Итак, пользователи делегируют управление своим кошельком другим сторонам с кворумом. MPC (Multi-Party Computation) мощен для делегирования ответственности за управление ключами разным сторонам, но у него также есть некоторые недостатки:

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

Еще один серьезный недостаток SSS заключается в том, что он восстанавливает закрытый ключ, обычно в браузере. Это огромный риск безопасности, когда открытый ключ доступен на стороне клиента. TSS никогда не восстанавливает ключ и использует MPC для федерации подписи по ключевым фрагментам.

4. Облачные решения TEE

Я не думаю, что облачные доверенные исполнительные среды (TEE) и решения на основе SSS настолько разные, но я все равно хотел объяснить, как они работают. Доверенные исполнительные среды функционируют точно так, как они закодированы; они неизменны (по крайней мере, они утверждают, что они), и TEE не показывает, что находится внутри даже владельцу TEE. Они предназначены для работы с целостностью - делать правильные вещи, даже если никто не наблюдает. Таким образом, ключи никогда не раскрываются клиенту, как только TEE выполняют свою работу правильно.

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

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

Облачные TEE выглядят многообещающе в теории, но в прошлом мы видели уязвимости, такие какsgx.failв облачных TEE. Однако преимущество TEE заключается в том, что даже если существует задняя дверь или уязвимость, злоумышленнику понадобится физический доступ к TEE, поэтому потребительское оборудование (Secure Enclave - Passkeys) настолько мощное, потому что ключ хранится внутри Secure Enclave пользователей, и только владелец может получить доступ к ключу, тогда как Cloud TEE хранят ключи в облаке, что делает их уязвимыми к атакам.

Не ваше безопасное убежище, не ваши монеты.

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

Если поставщики услуг выключают сервер, средства пользователей замораживаются, и никто не может получить к ним доступ. Ключи хранятся внутри Cloud TEE, что означает, что они могут цензурировать пользователей. Полное доверие только TEE для управления ключами создает единую точку отказа.

Ключи сеанса: новый способ ограниченных разрешений

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

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

Как и в мире Web3, мы определяем ключи сеанса как фреймворк, который потенциально может изменить взаимодействие пользователей с dApps. Целью ключей сеанса является позволение пользователям устанавливать предварительные одобрения на определенное время в различных сценариях и совершать транзакции без подписи. Но как это работает?

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

Лучшие комбинации аутентификации и управления ключами для различных случаев использования

Я объяснил различные системы управления ключами и их плюсы и минусы. С помощью силы AA мы можем объединить эти системы управления ключами и создать мощные структуры с минимальными компромиссами. Давайте объясним это. C.1) Passkey + восстановление с таймлоком - Clave - финтех-приложение, которое хранит ценные средства.

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

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

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

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

1. Пароль + восстановление с таймлоком + ключи сеанса - мобильное социальное приложение

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

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

Ключи сеанса являются лучшей альтернативой этому. Пользователи могут проверить, как долго сеанс будет активным и к каким активам сеанс может получить доступ, что снижает необходимость доверия к dApp. После истечения времени сеанса пользователи больше не должны беспокоиться о разрешениях = Больше не нужноrevoke.cashlike applications :)

2. Подписчик на основе MPC или облачной TEE + самостоятельный кастодиалный подписчик для выхода

Недостаток сторонних уровней управления ключами на основе MPC или Cloud TEE заключается в том, что большинство из них не являются некастодиальными и имеют значительные централизованные компоненты. Тем не менее, некоторые децентрализованные приложения требуют встроенных кошельков без дополнительных накладных расходов на газ, что требует решений на основе MPC или Cloud TEE. Добавление дополнительной подписи для «rage quit» может решить проблему цензуры, с которой сталкиваются эти системы управления ключами, а также смягчить потенциальные юридические проблемы, с которыми могут столкнуться эти dApps. Для этого вам понадобится умный кошелек, потому что ротация ключей невозможна с EOA.

Уже существует несколько приложений, которые используют эту архитектуру управления ключами.

3. 12 слов + Аппаратный подписчик для максимальной безопасности — опыт DeFi-расширения браузера

Пользователи DeFi любят опыт работы с расширениями браузера, и изменение поведения пользователей является одной из самых сложных вещей в современном мире. Так почему бы не создать лучшую альтернативу? Сочетание аппаратного подписчика (Secure Enclave или Passkey Signer) с 12-словными фразами доступными через расширение также может решить проблему утечки приватных ключей. Такой подход повышает безопасность без необходимости изменения поведения пользователей. Несколько команд в индустрии AA работают над его внедрением. (например,@myBraavos)

Умные аккаунты не достаточно умны

Представьте, что вы являетесь пользователем, который первым создал EOA с @MetaMaskа затем обнаружили альтернативу, такую как Zerion. Вы решаете использовать @zerion, и все, что вам нужно сделать, это импортировать свою мнемоническую фразу - просто. Теперь представьте, что вы пытаетесь сделать то же самое на Starknet, где все кошельки являются умными счетами. Вы не можете, потому что Braavos и Argent не совместимы. Эта проблема также существует в экосистеме EIP-4337 и@zkSyncродной АА.

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

Кроме того, функция «гневного выхода» должна быть функцией по умолчанию, так как центральные участники почти во всех ключевых системах управления могут быть отключены. Пользователям должно быть проще менять подписывающих сторон или переключаться между смарт-контрактами, а самостоятельный хостинг должен быть вариантом по умолчанию для пользователей. Существует два стандарта модульных смарт-счетов: ERC-6900 и ERC-7579. Они оба пытаются достичь одной и той же цели — сделать умные аккаунты умнее.

Особая благодарностьДерек ,Конрад, иNoamдля обратной связи и комментариев!

Отказ от ответственности:

1. Эта статья перепечатана из [X]. Все авторские права принадлежат автору оригинала [2077Исследование]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с gate Учитькоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно личными взглядами автора и не являются инвестиционными советами.
3. Команда Gate Learn перевела статью на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.