21wiki

Проверка подлинности программного обеспечения

· 6 мин чтения

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

ВопросИнструмент
Дошёл ли файл без изменений?контрольная сумма (sha256sum)
Тот ли человек его выпустил?подпись PGP
Соответствует ли бинарник исходникам?воспроизводимая сборка

Первые два разобраны в материале о проверке подписей, третий — в документации Bitcoin Core.

Немного терминологии

PGP (Pretty Good Privacy) — программа для шифрования и цифровой подписи сообщений и файлов, разработанная Филипом Циммерманом в 1991 году. В 1997 году появился открытый стандарт OpenPGP.

GPG (GnuPG, GNU Privacy Guard) — свободная альтернатива PGP под лицензией GNU GPL, полностью совместимая с OpenPGP. На практике вы почти всегда работаете именно с ней.

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

Подписывается не программа, а список хешей

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

Схема такая. Разработчик считает хеш каждого архива (обычно SHA-256), складывает их в файл SHA256SUMS и подписывает уже этот файл. Подпись кладётся рядом отдельным файлом SHA256SUMS.asc или .sig.

Для проверки нужны три файла:

  1. сам файл программы;
  2. подписанный файл с контрольными суммами;
  3. файл подписи.

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

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

Пропустите второй шаг — и вы проверили подлинность списка, но не файла. Пропустите первый — сверили файл со списком, который мог подсунуть кто угодно.

Иногда встречается и прямая подпись бинарника: например, у Electrum файл .asc подписывает сам AppImage. Тогда шагов остаётся два.

Проверка в консоли

Установите GPG (gpg --version покажет, что он уже есть). Если предпочитаете графический интерфейс, в исходном материале подробно разобран GpgFrontend — кроссплатформенный, с проверкой в пару кликов.

Шаг 1. Импортировать ключи разработчиков. Без публичного ключа проверить подпись нечем:

gpg --recv-keys <отпечаток>

Если сервер по умолчанию недоступен, укажите другой:

gpg --keyserver keyserver.ubuntu.com --recv-keys <отпечаток>

Шаг 2. Проверить подпись:

gpg --verify <файл подписи> <проверяемый файл>

Для отсоединённой подписи файла с суммами достаточно одного аргумента — GPG сам найдёт парный файл:

gpg --verify SHA256SUMS.asc

Шаг 3. Посчитать хеш и сравнить его со значением из SHA256SUMS:

sha256sum bitcoin-28.0-x86_64-linux-gnu.tar.gz

На macOS та же операция делается через shasum -a 256 <файл>, где -a 256 задаёт алгоритм. Для SHA-512 — -a 512, есть также sha512sum и md5sum.

Чего проверка сама по себе не доказывает

Самая частая ошибка — принять «подпись верна» за окончательный ответ. Проверка подтверждает, что файл подписан ключом с определённым отпечатком. Она не подтверждает, что этот ключ принадлежит нужному человеку.

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

gpg --edit-key <отпечаток> trust

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

Воспроизводимые сборки

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

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

Bitcoin Core отвечает на это загружаемыми (bootstrappable) сборками на основе Guix. Формулировка из документации проекта: подход усиливает гарантии безопасности бинарников, позволяя проверять и воспроизводить цепочку инструментов вместо слепого доверия скачанным бинарникам.

Как это устроено

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

Дальше работает коллективная проверка:

  1. Независимые сборщики собирают релиз у себя командой ./contrib/guix/guix-build.
  2. Каждый считает контрольные суммы полученных файлов — они собираются в SHA256SUMS.
  3. Каждый аттестует результат: подписывает свои суммы GPG-ключом и отправляет подпись в отдельный публичный репозиторий guix.sigs. Механика та же, что раньше применялась в gitian.sigs.
  4. Каждый может проверить чужие аттестации против своей: guix-verify сравнивает подписи других сборщиков с собственным результатом.

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

Отдельная тонкость с macOS и Windows: эти платформы требуют подписи кода производителя, поэтому у них появляются два набора сумм — noncodesigned.SHA256SUMS до подписания и all.SHA256SUMS после.

Что это даёт вам

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

Собирать самому при этом необязательно — но принципиально важно, что такая возможность есть и ею регулярно пользуются. Для самостоятельной сборки нужно около 16 ГБ на разделе с /gnu/store и ещё около 8 ГБ на каждую целевую платформу.

У Guix есть и собственная развилка доверия. Субституты — заранее собранные пакеты, скачиваемые с серверов сборки, — экономят часы времени, но возвращают часть доверия обратно. Отказ от них (--no-substitutes) означает сборку всего с нуля: первый прогон долгий, зато результат ни от кого не зависит.

Практический порядок действий

  1. Скачайте файл программы, файл SHA256SUMS и подпись SHA256SUMS.asc.
  2. Импортируйте публичные ключи разработчиков и сверьте отпечатки с независимым источником.
  3. Проверьте подпись: gpg --verify SHA256SUMS.asc.
  4. Посчитайте хеш скачанного файла и найдите его в SHA256SUMS.
  5. Только после этого запускайте установку.

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

Пробелы

Использованные источники описывают процедуру со стороны сборщика и релиз-менеджера Bitcoin Core. Не разобран инструмент contrib/verify-binaries, которым проверку можно выполнить одной командой, и не рассмотрено, как обстоят дела с воспроизводимостью у прошивок аппаратных кошельков — там практика заметно неоднороднее.

Источники

Дополнительные материалы

Карта связей

Упоминания