От защиты приватных ключей до системной обороны: как Crypto восстанавливает безопасность и доверие в эпоху ИИ?

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

За последние десять лет нарратив безопасности в криптоиндустрии почти полностью сводился к классическому лозунгу: «Не ваши ключи — не ваши монеты».

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

Однако недавние знаковые инциденты безопасности полностью разбивают иллюзии о такой однобокой защите.

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

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

Конкуренция в области криптобезопасности уже не сводится к тому, кто лучше защищает приватные ключи, а к тому, кто сможет создать более полную, более проверяемую и более устойчивую систему безопасности (дополнительное чтение: «Как хакеры, использующие ИИ, меняют гонку вооружений «щита и меча» в Web3?»).

1. Приватные ключи важны, но больше не являются всем

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

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

Инцидент с Binance 29 октября является типичным примером такого изменения.

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

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

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

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

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

Возьмем, к примеру, инцидент с Ledger: его чипы, операционная система и серверы не были взломаны, проблема возникла на этапе распределения, когда устройства покинули контроль производителя, и пользователи все еще могут столкнуться с атаками на этапе покупки и инициализации.

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

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

Но стоит отметить, что, сталкиваясь с этими изменениями, индустрия не ограничивается лишь обсуждением рисков.

2. Как криптоиндустрия обновляет свои меры безопасности от Binance до Ledger?

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

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

1. Binance и Coinbase: от защиты ключей к защите всего процесса подписания и движения средств

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

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

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

Похожая логика также прослеживается в недавно опубликованной системе защиты активов Coinbase.

4 ноября Coinbase опубликовала статью, в которой представила свою архитектуру безопасности активов клиентов и сообщила, что в настоящее время более 99% активов клиентов хранятся в холодных кошельках, а также раскрыла целый набор механизмов контроля движения средств.

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

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

Это, по сути, является ядром логики глубинной защиты (Defense in Depth).

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

2. Ledger и Trezor: безопасность начинает распространяться на производство, циркуляцию и этапы доставки

Изменения в области аппаратных кошельков также являются показательными.

После инцидента с аппаратным внедрением Ledger начала корректировать требования к управлению устройствами для авторизованных дистрибьюторов, требуя от них приостановить продажи в Юго-Восточной Азии и Гонконге, а также провести выборочную проверку устройств и инвентаризацию.

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

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

Корректировка Trezor была более прямой.

12 ноября Trezor опубликовал последние результаты расследования, подтвердив, что 3 устройства Trezor Safe 5, проданные через затронутого дистрибьютора CryptoBilis, имели аппаратное внедрение; одновременно Trezor объявил о сокращении своей сети авторизованных дистрибьюторов на 80% и потребовал от оставшихся партнеров соблюдать более строгие правила управления закупками, хранением и доступом к устройствам.

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

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

Для производителей кошельков это означает, что необходимо управлять не только чипами и прошивками, но и полным жизненным циклом продукта.

3. От инициативы по созданию альянса безопасности CZ до усилий регуляторов: отраслевое сотрудничество формирует реальные возможности

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

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

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

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

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

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

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

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

Стоит отметить, что после инцидента с Binance Комиссия по финансовым услугам Кореи (FSC) срочно собрала Финансовый надзорный институт, Корейский институт финансовой безопасности и основные платформы виртуальных активов для проверки состояния хранения активов и мер безопасности на биржах.

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

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

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

3. Какие новые стандарты безопасности нужны продуктам Crypto в эпоху ИИ?

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

Binance перестраивает внутренние системы и права доступа, Coinbase подчеркивает контроль с многоуровенной подписью, Ledger и Trezor ужесточают цепочку поставок, вся отрасль продвигает межплатформенное сотрудничество в экстренных ситуациях, а корейские регуляторы усиливают круглосуточный мониторинг и ответственность за инциденты.

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

1. От безопасности приватного ключа к безопасности прав доступа на всей цепочке

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

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

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

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

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

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

2. От одноразового аудита к постоянной верификации

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

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

Таким образом, в будущем система безопасности должна перейти от одноразового аудита к постоянной верификации.

3. От защиты в одной точке к глубокой защите

Нет ни одной технологии, которая могла бы решить все проблемы безопасности.

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

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

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

4. От «доверяй бренду» к «безопасность может быть проверена»

Для обычных пользователей существует давняя проблема безопасности: информационная асимметрия.

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

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

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

5. Возврат к контролю над активами пользователя: ценность и ответственность неуправляемых кошельков

После обсуждения множества механизмов безопасности стоит переосмыслить еще один вопрос:

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

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

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

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

Но это не означает, что неуправляемые кошельки могут быть иммунны ко всем атакам.

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

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

Это также более полная концепция безопасности.

Заключение

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

Приватные ключи по-прежнему важны, но приватные ключи больше не являются всем.

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

Для всей отрасли восстановление доверия не может быть достигнуто только с помощью одноразового аудита безопасности, одного доказательства резервов или одной фразы «активы пользователей не пострадали».

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