491 / 736REPRO

Reproducible Firmware Build

Відтворюване збирання прошивки

Коли ви оновлюєте апаратний гаманець (Hardware Wallet), то встановлюєте готовий файл. Як дізнатися, чи справді його створено з коду, опублікованого виробником? Reproducible Firmware Build дає іншій людині змогу незалежно зібрати те саме програмне забезпечення й порівняти результати. Так можна перевірити шлях від відкритого коду до випущеного оновлення.

Прошивка — це програмне забезпечення, яке керує пристроєм, наприклад Hardware Wallet. Її збирання є відтворюваним, якщо той самий вихідний код, визначене середовище та інструкції дають точно однакові, заздалегідь визначені файли. Однакового функціонування замало: порівнюють самі дані. Для підписаних випусків також має бути зрозуміло, як обробляється підпис.

Виробник може опублікувати код, який програміст здатен прочитати. Проте на гаманець зазвичай встановлюють готовий файл у машинному форматі — бінарний файл. Ці дві форми пов’язує процес збирання. Незалежна людина може повторити його та порівняти результат із випуском виробника. Шукають однакові байти, тобто окремі одиниці даних, часто за допомогою криптографічного хешу — відбитка, обчисленого з вмісту. Перевірка стосується визначених результатів, наприклад файла прошивки, а не автоматично всіх робочих файлів і журналів. [1] [4]

Уявімо двох розробників, які перевіряють одне оновлення. Назви проєкту замало: їм потрібен той самий commit, тобто точно визначена ревізія коду. Потрібні також версії підключених бібліотек і компілятора — інструмента, що перетворює код на машинну форму. Його параметри, важливі налаштування середовища та модель гаманця теж входять до процедури. Ці відомості мають бути визначені заздалегідь або записані під час збирання. Інакше обидві людини можуть працювати сумлінно, але отримати різні результати. [1] [2]

Відмінність не обов’язково означає, що хтось змінив поведінку програми. Компілятор може записати шлях робочої папки в інформацію для пошуку помилок. Якщо розробники зберігають проєкт у різних місцях, файли можуть відрізнятися. Допомогти може визначений шлях або підтримуваний спосіб уніфікації шляхів. Це правило має бути відомою частиною процедури. Видаляти незрозумілі відмінності після невдалої перевірки лише заради збігу означає позбавляти перевірку сенсу. [3]

Цифровий підпис дає змогу перевірити відповідність файла підпису, створеному певним ключем. Пов’язати цей ключ із виробником — окрема складова довіри. Відтворюване збирання відповідає на інше запитання: чи відповідає файл визначеному вихідному коду? Обидві перевірки доповнюють одна одну. Офіційне оновлення може містити дані підпису, яких немає в локальному результаті. Тому порівняння цілих файлів без розуміння формату може показати відмінність навіть за правильного збирання програми. [5]

Документація Trezor описує вибір версії й моделі, збирання прошивки та порівняння з офіційним файлом. Локальний результат не підписаний так само, як випуск виробника, тому процедура спершу зануляє точно визначені поля підпису. Старі формати також відрізняються заголовками — початковими частинами файлів із відомостями про них. Структура залежить від моделі та версії, тож інструкцію для одного пристрою не можна без перевірки переносити на інший. Початковий підпис перевіряють окремо; порівняння змінених копій цього не замінює. [5]

Спочатку слід з’ясувати, чи справді порівнювали ту саму ревізію, модель і варіант прошивки. Далі перевіряють інструменти, бібліотеки та передбачені перетворення файла. Оригінальні файли й запис відмінностей потрібно зберегти. Причиною може бути помилка середовища чи інструкцій, але також зміна розповсюджуваної програми. Сама розбіжність не визначає ні винуватця, ні причину. Доки її не пояснено й перевірку не повторено, називати збирання перевіреним не можна. [1] [4]

Якщо помилка вже є в опублікованому коді, кожне повторне збирання може точно її відтворити. Спільний ненадійний компілятор теж здатен додати однакову шкідливу зміну до всіх результатів; повторне використання не є незалежною перевіркою інструмента. Закриті бінарні компоненти обмежують те, що можна зібрати з доступного коду. А збіг файла на комп’ютері не доводить, що конкретний гаманець справжній або працює саме з цією прошивкою. Перевірка походження файла — важлива частина безпеки, але не повний її доказ. [6] [1]

Позначка «перевірено» корисна тоді, коли відомо, хто виконав перевірку, яку ревізію зібрав, для якої моделі та за якою процедурою. Звіт має називати порівняні файли, функцію хешування, результати й точний спосіб обробки даних підпису. Тоді інші люди можуть вивчити або повторити роботу. Більше незалежних збирань зменшує залежність від одного видавця. Проте перевірка коду, процесу оновлення та самого пристрою залишається необхідною. [2] [4]

Приклад · REPRO

Два однакові результати й інший хеш

Двоє розробників збирають ту саму ревізію прошивки для тієї самої моделі в однаковому середовищі. Відбитки SHA-256 їхніх файлів збігаються, а відбиток офіційної підписаної версії відрізняється. Якщо документація точно визначає поля підпису, вони виконують передбачене перетворення на копіях і порівнюють знову. Тоді збіг стосується саме визначеного вмісту. Початковий підпис усе ще потребує окремої перевірки; інші непояснені відмінності не можна просто видалити.

Для повної картини прочитайте також Hardware Wallet, Private Key, Cold Storage, Secure Element. На цю статтю також посилаються COLDCARD RNG Incident (2026).

01Чи потрібно мені самому збирати прошивку?

Щоб зрозуміти результат перевірки, не обов’язково бути програмістом. Але переконайтеся, що незалежний звіт указує конкретні версію, модель і порівняні файли. Однаковий хеш не доводить відсутності помилок: той самий шкідливий код або компілятор може створювати однакові файли. Перевірка коду й довіра до пристрою залишаються окремими питаннями.

02Чи означає інший хеш підписаного оновлення атаку?

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

DOC · 001Reproducible Builds — DefinitionДокументація DOC · 002Reproducible Builds — Recording the environmentДокументація DOC · 003Reproducible Builds — Build pathsДокументація DOC · 004Reproducible Builds — Build infrastructure threatsДокументація DOC · 005Trezor — Reproducible build verificationДокументація DOC · 006Wheeler — Countering Trusting TrustПервинне джерело
Переглянуто: Спочатку джерела · Не інвестиційна порада