Розкриваючи справжні межі самостійного зберігання: випадок з Ledger

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

15 жовтня 2026 року компанія Ledger офіційно відреагувала на цей інцидент: зловмисники купили оригінальні пристрої, розібрали їх і вбудували апаратуру, а потім через дистриб'юторів у Південно-Східній Азії знову вивели на ринок. Ledger підкреслила, що чипи, операційна система та сервери не були зламані, це було кваліфіковано як атака на локальні канали дистрибуції, а не системне вторгнення в ланцюг постачання.

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

Хто є власником цифри не важливо. Важливо те, що вона виявляє.

1. Самостійне зберігання не усуває ризики, а лише змінює їх місце

Протягом останніх десяти років індустрія розповідала дуже чисту історію: якщо ви зберігаєте монети на біржі, ви передаєте свою долю компанії; якщо ви тримаєте приватний ключ у своїх руках, ви вільні.

Ця історія частково правдива.

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

Але самостійне зберігання не є кінцевою точкою ризику, а є його перенесенням.

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

У цій низці питань будь-який з етапів, що піддається ризику, призводить до результату, який не відрізняється від того, що сталося, коли біржа зникла. Оцінка в 93 мільйони доларів, надана третьою стороною, по суті, є уроком.

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

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

Найслабшою ланкою в моделі безпеки завжди є не алгоритми, а люди, пристрої та процеси.

2. Розділіть одиночний приватний ключ на кілька перевіряємих умов

Справжній урок інциденту з Ledger не в тому, щоб «не використовувати апаратні гаманці», а в тому, що покладатися лише на припущення «приватний ключ у мене в руках» є одиничною точкою відмови.

Правильний напрямок полягає в тому, щоб для переміщення коштів потрібно було одночасно виконати кілька умов, які розподілені в різних зонах довіри.

Позиція TBC у цій справі потребує стриманості. Вона не стверджує, що може усунути атаки на термінали, жоден ланцюг не може цього зробити. Її цінність полягає в тому, що UTXO рідні контракти та багатопідписні інструменти дозволяють проектам розділити ризик одиночного приватного ключа на кілька перевіряємих умов.

Конкретно, TBC використовує SHA256 PoW та UTXO модель, код вузлів TBCNODE є відкритим для перевірки. Природна характеристика UTXO моделі полягає в тому, що кожен невитрачений вихід може бути обмежений незалежними умовами скрипта, а не прив'язаний до глобального балансу рахунку. Це означає, що правила витрат можуть бути записані в ланцюг, а не в якесь бекенд-сервіс.

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

Тут потрібно сказати все: багатопідпис є налаштовуваним інструментом контролю ризиків, а не автоматичною безпекою, і не є абсолютною безпекою.

Якщо хтось вважає, що налаштування 2 з 3 вирішує всі проблеми, то це та ж сама помилка, що й вірити, що «купивши апаратний гаманець, ви в безпеці». Багатопідпис змінює структуру витрат на атаки, а не ймовірність атак.

Документація TBC AMM пояснює ще одну річ: SDK будує, оцінює та підписує локально, трансляція ініціюється явно додатком; стан пулу та контроль активів залежать від UTXO та правил скрипта. Це становить основу для некерованих угод та розділення прав.

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

3. Чому багатопідпис часто є лише формальним розподілом

Це найпростіша частина, яку можна пропустити, і вона є найсмертельнішою.

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

Зловмисник, отримавши одну мнемонічну фразу, отримує всі права підпису. Якщо пристрій було зламано один раз, це означає, що всі пороги одночасно піддаються ризику. У такій конфігурації на ланцюгу це виглядає як 3 з 5, але в реальності це 1 з 1.

Отже, справжнє питання не в тому, «скільки підписів я налаштував», а в кількох більш жорстких питаннях:

• Чи є середовище генерації цих ключів незалежними?
• Чи зберігаються вони на фізично ізольованих різних пристроях?
• Чи є особа, що ініціює угоду, і особа, що затверджує угоду, однією й тією ж особою?
• Чи є затримка та ручна перевірка для високоризикових переказів?
• Чи були проведені тренування для процесу обертання ключів та відновлення?

Модель UTXO TBC не відновить вкрадений приватний ключ. Це потрібно визнати. Правила на ланцюгу можуть лише запобігти несанкціонованому переміщенню коштів, коли певна умова порушена; вони не можуть відновити активи, якщо приватний ключ вже був скомпрометований.

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

Ще один аспект, який потрібно відверто визнати: TBC сама повинна продовжувати вдосконалюватися. Легкість взаємодії багатопідпису, глибина сумісності з основними апаратними гаманцями, шаблони прав, готові до використання, незалежні сторонні бенчмарки, а також постійний аудит SDK, гаманців та компонентів AMM - це все ще в процесі.

TBCNODE вже має записані версії безпеки від CertiK та SlowMist. Але аудит може лише підтвердити, що певна версія, певна область була перевірена, він не охоплює апаратні термінали, не охоплює звички управління ключами користувачів, не охоплює код, який буде подано в майбутньому, і не охоплює всю логіку прикладного рівня. Вважати аудиторський звіт сертифікатом безпеки - це ще одна форма лінощів.

4. Справжнє самостійне зберігання - це правило на ланцюгу

Повертаючись до того зламаного пристрою.

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

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

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

Справжнє самостійне зберігання - це не лише один приватний ключ, а й те, що після будь-якої одиничної втрати, правила на ланцюзі все ще можуть запобігти несанкціонованому переміщенню коштів.

Джерела Посилання: Ledger · Tom's Hardware · TBCNODE · Contract SDK · MultiSig · AMM · CertiK · SlowMist