Разобрав подлинный Ledger, TBC обсуждает истинные границы самоуправления

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

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

14 октября Tom's Hardware, ссылаясь на отчет Bloomberg, оценил убытки примерно в 93 миллиона долларов. Важно уточнить: эта цифра поступила от третьих лиц и не была подтверждена официальным заявлением Ledger.

Не так важно, кому принадлежит эта цифра. Важно то, что она раскрывает.

I. Самоуправление не устраняет риски, а лишь меняет их местоположение

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

Эта история отчасти верна.

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

Но самоуправление не является конечной точкой риска, а лишь переносом риска.

Это меняет вопрос «может ли платформа злоупотребить» на другой ряд вопросов: откуда ваше устройство? Изменен ли его прошивка? В какой среде была сгенерирована мнемоническая фраза? Совпадает ли информация, отображаемая на экране во время подписания, с фактически подписанной транзакцией? Кто имеет право инициировать этот перевод?

В этой цепочке вопросов любой сбой в одном из звеньев приведет к тому же результату, что и кража на бирже. Оценка в 93 миллиона долларов по сути покупает этот урок.

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

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

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

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

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

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

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

Конкретно, TBC использует SHA256 PoW и модель UTXO, код узла TBCNODE открыт для проверки. Естественная особенность модели UTXO заключается в том, что каждый неиспользованный выход может быть ограничен независимыми скриптовыми условиями, а не зависеть от глобального баланса счета. Это означает, что правила расходования могут быть записаны в цепочку, а не в каком-либо бэкэнд-сервисе.

SDK tbc-contract предоставляет возможность запроса в цепочке, получения UTXO, построения транзакций, подписания и трансляции, а также включает MultiSig, NFT, FT и рабочие процессы Pool. Официальный пример MultiSig поддерживает установку от 1 до 6 порогов подписания среди 3 до 10 публичных ключей, в документации приведен пример 2 из 3.

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

Если кто-то думает, что наличие 2 из 3 решает все проблемы, то это такая же ошибка, как и вера в то, что «покупка аппаратного кошелька обеспечивает безопасность». Мультиподпись изменяет структуру затрат на атаки, а не вероятность атак.

Документация TBC AMM объясняет еще одну вещь: SDK строит, оценивает и подписывает локально, трансляция инициируется приложением явно; состояние пула и контроль активов зависят от UTXO и скриптовых правил. Это составляет основу для неуправляемых транзакций и разделения полномочий.

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

III. Почему мультиподпись часто является лишь формальным разделением

Это самый легко пропускаемый и самый смертельный момент.

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

Злоумышленник, получивший одну мнемоническую фразу, получает все права подписи. Если устройство было скомпрометировано один раз, это означает, что все пороги одновременно потеряны. Эта конфигурация на цепочке выглядит как 3 из 5, но в реальности это 1 из 1.

Поэтому действительно важно не «сколько подписей я настроил», а задавать более жесткие вопросы:

• Является ли среда генерации этих ключей взаимно независимой?
• Хранятся ли они на физически изолированных разных устройствах?
• Являются ли инициатор и утверждающий транзакцию одним и тем же человеком?
• Есть ли задержка и ручная проверка для высокорисковых переводов?
• Прошли ли процессы ротации ключей и восстановления практику?

Модель UTXO TBC не может автоматически исправить украденный приватный ключ. Это необходимо признать. То, что могут делать правила на цепочке, — это предотвратить несанкционированный перевод средств, когда какое-либо условие нарушено; но они не могут восстановить активы, если приватный ключ уже был скомпрометирован.

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

Также необходимо откровенно признать: TBC сама должна продолжать улучшаться. Удобство взаимодействия с мультиподписью, глубина совместимости с основными аппаратными кошельками, шаблоны разрешений, готовые к использованию, независимые сторонние тесты, а также постоянный аудит компонентов SDK, кошелька и AMM — все это находится в процессе.

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

IV. Истинное самоуправление — это правило на цепочке

Вернемся к разобранному устройству.

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

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

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

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

Источник информации Ссылки: Ledger · Tom's Hardware · TBCNODE · Contract SDK · MultiSig · AMM · CertiK · SlowMist