«Приватный ключ не был скомпрометирован» — самое опасное плацебо: как выбрать действительно надёжные средства шифрования?

Автор: imToken

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

Ответ, очевидно, не так прост.

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

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

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

В конце концов, безопасность приватных ключей — лишь начало обеспечения безопасности криптоактивов, а не их конечная цель.

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

1. Как злоумышленники обходят приватные ключи и как теряются активы и данные?

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

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

• На примере инцидента с Bybit: злоумышленники с помощью социальной инженерии скомпрометировали устройство разработчика Safe, получили соответствующие учетные данные для доступа и тем самым захватили контроль над фронтенд-ресурсами инфраструктуры кошелька Safe;
• В случае с Bitget злоумышленники использовали уязвимость в стороннем средстве защиты, чтобы получить внутренние учетные данные с высокими правами, а затем обошли существующие механизмы риск-менеджмента через поддельные инструкции на вывод средств;
• При последнем крупном инциденте с Binance вектор атаки, вероятно, начинался с компрометации ноутбука инженера DevOps (однако позже Binance заявила, что при дальнейшем расследовании были обнаружены другие точки вторжения, поэтому полная схема атаки все еще требует подтверждения);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Контроль над приватным ключом: кто на самом деле управляет активами?

Это базовый и наиболее важный вопрос при оценке архитектуры безопасности криптопродукта.

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

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

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

Некостодиальные кошельки работают иначе.

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

С архитектурной точки зрения между ними наблюдается явное различие:

• Централизованный кастодиальный контроль: Пользователь → система аккаунтов и прав платформы → контролируемую платформой систему кошельков → активы в блокчейне;
• Некостодиальный кошелек: Пользователь владеет приватным ключом → кошелек предоставляет инструменты управления и подписания → адресу на блокчейне, контролируемый напрямую пользователем;

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

Безусловно, это не гарантирует абсолютной безопасности некостодиальных кошельков.

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

Поэтому при выборе кошелька рекомендуется четко ответить как минимум на три вопроса: где генерируется приватный ключ — на устройстве пользователя или на стороне сервера? Будут ли приватный ключ и мнемоническая фраза загружаться на сервер провайдера? Имеет ли пользователь полный контроль над правом подписи и сможет ли восстановить свои средства в других совместимых кошельках?

2. Конфиденциальность данных: какую информацию о вас на самом деле собирает продукт?

Второй аспект — защита конфиденциальности, которую многие пользователи склонны упускать из виду.

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

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

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

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

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

При централизованном хранении таких данных злоумышленникам значительно проще составить полный профиль пользователя, что открывает путь для так называемой «атаки с использованием монтировки за 5 долларов», поскольку никакие криптографические алгоритмы не защитят от ситуации, когда злоумышленник физически находит владельца активов (Дополнительное чтение: «Осенний шторм для Web3-кошельков»: как понять эволюцию «меча и щита» в безопасности Crypto в эпоху ИИ?)

3. Архитектура безопасности: какие механизмы прошли постоянное подтверждение?

Третий аспект — технологический потенциал обеспечения безопасности, заложенный в продукт.

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

Тем не менее, независимо от типа продукта существуют общие критерии оценки.

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

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

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

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

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

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

Надежная система безопасности должна максимально локализировать риски: даже при сбое отдельного звена это не должно приводить к мгновенной и полной потере контроля пользователей над своими активами.

3. Как Web3-продуктам строить долгосрочную систему безопасности?

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

1. Некостодиальная архитектура: передача приватных ключей непосредственно пользователям

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

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

В настоящее время программный кошелек imToken использует встроенные в iOS и Android безопасные источники энтропии для локальной генерации приватных ключей, а основной программный модуль TokenCore открыт с 2018 года.

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

Ценность такого дизайна выходит за рамки простой выдачи пользователю набора слов восстановления.

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

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

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

Что касается конфиденциальности данных, imToken публично заявлял, что использует такие инструменты разработки, как Sentry и Firebase, для отчетности об ошибках и сбора статистики, однако не собирает чувствительные данные, связанные с безопасностью самого кошелька. Это подчеркивает необходимость строгого разделения метрик работы продукта и ключевой информационной безопасности (приватных ключей, мнемонических фраз) на этапе проектирования.

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

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

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

3. Безопасность — это не гарантия неизменности от атак, а изоляция рисков от активов

Для пользователей, долгосрочно хранящих значительные объемы криптоактивов, использование исключительно обычных онлайн-устройств未必 является оптимальным методом управления средствами.

Помимо аппаратных кошельков, imToken позволяет осуществлять передачу данных о транзакциях между полностью офлайн-кошельком и watch-only кошельком посредством QR-кодов.

Конкретно, пользователь может взять старый смартфон, больше не подключенный к интернету, установить на него imToken и создать полностью автономный кошелек, а затем настроить взаимодействие с watch-only кошельком на другом онлайн-устройстве через сканирование QR-кодов по стандарту ERC-4527.

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

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

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

imKey построен на базе защищенных чипов Infineon серии SLE78, а его базовая платформа контроллера M7893 получила расширенную сертификацию CC EAL6+, обеспечивая безопасное хранение, безопасную загрузку и генерацию истинно случайных чисел.

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

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

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

Заключение

Анализируя серию недавних инцидентов с участием Binance, Coinbase, Ledger и Keystone, мы видим, что границы безопасности криптопродуктов становятся всё более размытыми и сложными.

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

Обычным пользователям при выборе криптопродукта стоит изначально задать себе три вопроса:

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

Ни один продукт не способен гарантировать абсолютную безопасность.

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

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